| Age | Commit message (Collapse) | Author |
|---|
|
This never made any attempt to notice when the gtk_fb window was
destroyed externally. For now I've just done this a bit
hackishly to make things reasonably sane.
gtk_fb needs to be revisited in general to firm things up, and
til_fb needs better defined semantics surrounding acquire/release
vs. init/destroy. A lot of this is vestigial from early
rototiller days.
This is good enough for now to silence the gtk warnings about
destroying the c->image after the containing window destruction
already discarded it.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Simultaneously update includes and call sites to reflect the new
til_ prefix, preserving buildability.
|
|
This wires up the "configure-event" signal on the fb window to trigger
fb_rebuild() on resizes in the subsequent gtk_fb_page_flip().
|
|
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.
|
|
This too will automatically get removed on widget destroy
|
|
Destroying c->window, the container of c->image, will already
do that.
|
|
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.
|
