Age | Commit message (Collapse) | Author |
|
This wires up the "configure-event" signal on the fb window to trigger
fb_rebuild() on resizes in the subsequent gtk_fb_page_flip().
|
|
Make sure there's no outstanding workers potentially scribbling into a
page before tearing down the fb and its pages.
|
|
Pages get allocated before fb_acquire, and when creating similar
pages to the underlying window it creates a depenency on the
window being available before acquire. So move the window
create/destroy to the fb init and shutdown, acquire/release now
operate on the image within.
This commit also switches to using:
gdk_window_create_similar_image_surface()
for allocating pages, which may be more performant on backends
like X through the use of shared memory.
|
|
After some discussion with chergert on how this could be quicker
on X, it seemed worth noting at least something to this effect.
The details of doing this seemed annoying, because cairo apparently
doesn't just give you an xshm if appropriate via
gdk_window_create_similar_image_surface()
If that was all that were needed, this commit would just change the
cairo_image_surface_create() over to that. But chergert claimed it
doesn't do the right thing here, so a comment it is until someone
cares enough to to investigate further.
|
|
Just an ergonomic improvement, submodule bump and code change
done at once to keep things bisectable.
|
|
This too will automatically get removed on widget destroy
|
|
Destroying c->window, the container of c->image, will already
do that.
|
|
vim droppings
|
|
Now it actually builds! Hopefully for more than just me...
|
|
This deadlocks after a few "Go!" cycles, and the "rtv" module's
"snow" doesn't seem to be drawing anything, despite the explicit
use of "snow" working fine. I suspect it has to do with the lack
of module setup occurring, rtv may have a broken assumption about
the snow module always being setup at runtime and no static default
compiled in. I didn't go look yet.
There's plenty of TODOs and such to take care of, but this looks like
a good foundation to potentialy collaborate on and start thinking about
how things like libhandy would integrate and what directions things
must go to make that workable.
|