Add atsign-guarded for creating callbacks that don't corrupt Gtk state

[timholy]

Currently while developing a new application, it's easy to corrupt Gtk state by writing a callback that throws an error; when that happens, you have to quit julia and start all over again. This adds a convenience macro, @guarded, that can be applied to any function definition to prevent corruption.

[timholy]

Now passing tests.

[vtjnash]

This is roughly what the sigatomic macro in Gtk is supposed to do, so this would only be applicable to the "fast" callback interface.

[timholy]

It doesn't, though:

julia> using Gtk.ShortNames

julia> c = @Canvas()

julia> win = @Window(c)

julia> showall(win)

julia> draw(c) do widget
           error("oops")
       end
ERROR: oops
 in error at ./error.jl:21
 in anonymous at none:2
 in draw at /home/tim/.julia/v0.4/Gtk/src/cairo.jl:82
 in draw at /home/tim/.julia/v0.4/Gtk/src/cairo.jl:75
 in eval_user_input at REPL.jl:64
 [inlined code] from REPL.jl:93
 in anonymous at task.jl:68

# Now resize
julia> FATAL ERROR: Gtk state corrupted by error thrown in a callback:
ERROR: oops
 in error at ./error.jl:21
 in anonymous at none:2
 in draw at /home/tim/.julia/v0.4/Gtk/src/cairo.jl:82
 in notify_resize at /home/tim/.julia/v0.4/Gtk/src/cairo.jl:59

ERROR (unhandled task failure): oops
 in error at ./error.jl:21
 in anonymous at none:2
 in draw at /home/tim/.julia/v0.4/Gtk/src/cairo.jl:82
 in notify_resize at /home/tim/.julia/v0.4/Gtk/src/cairo.jl:59

Moreover, because of #161 the "fast" interface is necessary for most things.

[timholy]

Ah, sigatomic doesn't apply to canvases because their callbacks are written with the "fast" interface. That explains things. Should we use @guarded internally for draw and functions like mousedown_cb?

[lobingera]

@timholy @vtjnash
It might be only my understanding, but could (in general) split into a 'plain' GtkCanvas, where the user deals with raw signals and connects everything by hand and this GeneralCanvas that attaches all the magic things, including back store for drawing?

I'm using something like this here
https://gist.github.com/lobingera/2e7a9e4f8579b82d9fe5
and have code changes to Cairo.jl and Gtk.jl to support this (look in my github repository)

Gtk drawing is internally already cairo based and you get a proper context provided by the 'draw' call (or similar). The change to Cairo.jl is accepting this context and put it into Cairo.jl shape. In Gtk.jl i add a boolean input to the GtkCanvas constructor to get 'raw' signal access.

I have two reasons to do this:

1. I used it like this in C and python programs already and this follows closely the Gtk documentation
2. draw by using the provided context is (dependent on the underlying layers) faster. On some systems by far. The Gtk.jl method of a backstore as bitmap image is quite helpful but libcairo directly drawing to X11 can be hardware accellerated vs drawing to bitmaps via the pixmap renderer.

Sorry for trying to highjack the discussion, i should have opened (and planned to do) this earlier, but due to other allocations, i could not follow up or drive a discussion.

And Tim is creating new state of the art at the moment with incredible speed...

[lobingera]

@timholy , @vtjnash

I was trying to work around the 'plain canvas' issue and then learned, that with #169
i get what i want for free: I can replace the already assigned signal handlers with my own code.

Thank you.

[timholy]

You're most welcome. Glad that does what you want!

[vtjnash]

It might be only my understanding, but could (in general) split into a 'plain' GtkCanvas, where the user deals with raw signals and connects everything by hand and this GeneralCanvas that attaches all the magic things, including back store for drawing?

My general plan for Canvas has been to keep it as the "GeneralCanvas" object as you described it. For any other purpose, I was intending and expecting that users would copy the file and make their own derivative of GtkCanvas that implements the desired behavior

[vtjnash]

The Gtk.jl method of a backstore as bitmap image is quite helpful but libcairo directly drawing to X11 can be hardware accellerated vs drawing to bitmaps via the pixmap renderer.

note that the current double-buffering / early-draw technique should also already be rendering to the hardware-accelerated backend

[lobingera]

Depending in your system. With cairo-trace-perf (cairo's own benchmarking on your data) i saw clearly speedups on the x11 and xcb render in comparison to image. Second thing is, GTK not only provides the cairo context, but also a valid clipping path. This can speed up redrawing partially hidden Windows.

[vtjnash]

perhaps, but the computation of that mask can be very expensive, so I expect you are more likely to save memory than time, but at the cost of vastly slower redraw times when portions of the environment change (or this at least is what Apple would have me believe with their claims of overdrawing and quartz in general, rather than rastorizing only the visible pixels).

i've also seen cairo appear to do some sort of "lazy-render", so that the cost of rendering the final frame appeared to be delayed until it had a clipping path and was being copied to the screen.

note too that Canvas usually should not be using the Cairo RGB image backend; where supported it should be using an off-screen render buffer.

[timholy]

@lobingera, some benchmarks with numbers would be great.