summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-03-22gtk_fb: when creating page surfaces don't inherit scalingVito Caputo
When calling gdk_window_create_similar_image_surface() I was supplying '0' for the scaling factor which is just a blind "inherit scaling from the window" request. This is fine when the window isn't being scaled; everything is just 1:1. But when the window is scaled, and our output has been sized according to the widget allocation (unscaled), these scaling factors can't be the same if we intend for the page contents to fill the scaled output. Specify a scale of 1 instead, as that's how the allocation size coordinates should be viewed, like normalized units. The window scale is how many times those units the window coordinates are in. This should fix highdpi/GDK_SCALE=2 usage.
2022-03-22gtk_fb: tidy up size-allocate handlingVito Caputo
Since the callback is explicitly accessing c->image, yet was registered on c->window, there was a theoretical race there where c->image could have been accessed by the callback before gtk_fb_acquire() had assigned it. Instead just connect to the signal in gtk_fb_acquire() and do it on c->image instead of the window. Also request the configured size on c->image so the size allocation reflects the configured size when the callback fires.
2022-03-21gtk_fb: s/configure-event/size-allocate/Vito Caputo
The existing code made assumptions about the top-level window's configure-event dimensions reflecting the underlying GtkImage's dimensions. This happened to be true most of the time on X11 desktops, but client-side decorations have broken this assumption. Instead resize the fb on size-allocate, and get the size allocation out of the GtkImage widget *after* event propagation finishes. Thanks to chergert@redhat.com for assistance with quickly sorting this out and providing the patch, and elektron@halo.nu reporting the issue after testing on a librem5/phosh.
2022-03-19glimmer: first stab at adding settings supportVito Caputo
This bumps the rototiller submodule for the new described settings stuff, among other improvements. There are some ugly kludges surrounding widget lifecycle since I destroy setting widgets from their signal callbacks and that seems to anger gtk/glib. I'm unclear on what the right way is here, but leaking for now is relatively harmless. It seems like gtk+ should be holding a reference on the respective widget across signal deliveries so the callbacks can potentialy destroy them with the underlying resource freeing becoming queued. Perhaps there's something like signal propagation up the heirarchy happening and since I'm destroying the settings frame higher up the tree and not the specific widget being signaled things fall over. It's a TODO item to sort out, at least the resources leaked aren't substantial and it's only on interactive configuration. This has also been done in fashion preserving the --module=foo,bar=baz arguments consistent with classic rototiller. You can start glimmer with the same syntax --module= flag, and it will select the specified module and apply the supplied settings in a way reflected in the GUI. There should probably be a new '--go' flag added to enable starting the rendering via commandline. As-is glimmer will always leave you at a settings dialog waiting for a "Go!" click, even if you specified module+settings comprehensively via the CLI.
2022-03-14main: s/fb_settings/video_settings/Vito Caputo
mechanical rename making consistent with til_args_t naming
2022-03-14rototiller: bump submodule for til_args_tVito Caputo
preparatory for supporting rototiller style cli arguments
2021-10-01*: bump rototiller submodule for libtil renameVito Caputo
Simultaneously update includes and call sites to reflect the new til_ prefix, preserving buildability.
2021-02-18gtk_fb: integrate fb_rebuild() to handle resizesVito Caputo
This wires up the "configure-event" signal on the fb window to trigger fb_rebuild() on resizes in the subsequent gtk_fb_page_flip().
2021-02-18rototiller: bump submodule for fb_rebuild()Vito Caputo
fb_rebuild() has been added to facilitate window resizing This also fixes the unconfigured rtv snow handling
2021-02-17rototiller: bump submodule for cancellation safetyVito Caputo
This should eliminate most if not all of the deadlocking on module switching problems...
2021-02-17main: rototiller_quiesce() before fb_free()Vito Caputo
Make sure there's no outstanding workers potentially scribbling into a page before tearing down the fb and its pages.
2021-02-17rototiller: bump submodule for rototiller_quiesce()Vito Caputo
Since glimmer tears down and brings back up the world at will, it needs a way to synchronize with idling the threaded renderer. This may go away if librototiller gets refactored a bit to where the main rendering loop moves into librototiller, but as long as that's driven externally there needs to be a way to coordinate at this level.
2021-02-17gtk_fb: move window_{new,destroy} to fb_{init,shutdown}Vito Caputo
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.
2021-02-17gtk_fb: add note about xshm surfacesVito Caputo
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.
2021-02-17rototiller,main: bump rototiller, use new _free() styleVito Caputo
Just an ergonomic improvement, submodule bump and code change done at once to keep things bisectable.
2021-02-17gtk_fb: no need to explicitly remove tick_callbackVito Caputo
This too will automatically get removed on widget destroy
2021-02-17gtk_fb: no need to destroy c->imageVito Caputo
Destroying c->window, the container of c->image, will already do that.
2021-02-16main: remove spurious pasteVito Caputo
vim droppings
2021-02-16autotools: introduce rudimentary autotools setupVito Caputo
Now it actually builds! Hopefully for more than just me...
2021-02-16src: initial commit of something semi-workingVito Caputo
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.
2021-02-16rototiller: vendor rototiller submoduleVito Caputo
glimmer is a gtk frontend for rototiller
© All Rights Reserved