Re: gtk_style_context_get()

[Alexander Larsson <alexl redhat com>]

On fre, 2015-01-30 at 05:51 +0100, Benjamin Otte wrote:

> <Company> yes
> <Company> when the frame clock triggers, we (1) recompute styles, (2)
> size_allocate everything pending, (3) draw
>
> <mclasen> whether css values are up-to-date at other points in the
> frame cycle should not be important
> <mclasen> except for those 3rd party users who randomly poke at style
> contexts...
> <Company> but it is important
> <Company> otherwise you get shrinking gnome terminals and white
> firefox text
> <Company> the gnome terminal case is actually rather complex to get
> right with the "should not be important" assumption
> <Company> because it needs to compute a bunch of values based on
> multiple different widgets
> <Company> and it needs to compute those before size allocation happens
> <Company> in short: It needs to happen in style_updated() at the
> latest - but which style-updated, when it depends on multiple widgets?

What if we made style_updated its own phase in the frame cycle? Then we
would run style update on all (invalid) widgets before we reach layout
(size_allocate)?

It seems a bit weird to me to request CSS values outside of either
size_allocate or drawing. Is there really a sane usecase for this? The
one thing that seems somewhat common/useful is if you want to render a
widget to something like an offscreen or for an effect. But, what do you
really want to draw in this case? The state of the widget hierarchy at a
random point could be in a wildly inconsistent state (due to e.g. css
changes or size changes).

The three possible states that you would want to render is "what was
drawn last frame", "what will be drawn next frame" or "what would be
drawn if a size_allocate+draw cycle was initiated right now".
The first is essentially impossible for us, since we don't store data
from old frame state, the second is a bit painful if you want to draw
something that is not an actual on-screen-frame (as it waits for the
vblank, etc). So, the more realistic one is the last, but that requires
us to be able to trigger the entire frame cycle at any point, in
response to e.g. an out-of-frame gtk_widget_draw().

If we had something like this the gnome-terminal case could also use it
to trigger a full relayout (including css validation and size
allocation, but not the draw part in this case) before calculating the
geometry hints (if that has to happen out of frame).


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a short-sighted coffee-fuelled cowboy with a secret. She's a blind 
French-Canadian cab driver on the trail of a serial killer. They fight 
crime!