The logic here seems faulty. We want to keep
a timestamp that tells us when the glyph was
last used, so always update the timestamp.
And whenever we use a glyph, it turns 'young'
again, so remove it from the old pixels
accounting.
The (MAX_AGE, MAX_AGE+CHECK_INTERVAL) interval
is only relevant to prevent us from turning
a cached glyph old more than once, and that
is already taken care of.
This adds specific marshallers for all of the locations where a generic
marshaller is being used. It also provides va_marshallers to reduce the
chances that we get stack traces from perf going through ffi_call_unix64.
This is forward ported from gtk-3-24.
# Conflicts:
# gtk/gtkeventcontrollerkey.c
# gtk/gtkeventcontrollermotion.c
# gtk/gtkgesture.c
# gtk/gtkgesturemultipress.c
If somebody does a transform like
scale(5) scale(10) translate(1,1) translate(5,0)
store it instead as
scale(50) translate(6,1)
This way, less memory is consumed and transforms are easier to read.
In particular, this simplifies the typical transforms we do in GTK,
which are just one translation after another.
We don't need to just look at the scale of the new modelview matrix, but
at the one we get when multiplying the new one with the current one.
Test case attached.
1) In the SetWindowPos() function (and the WINDOWPOS struct) the
"hWndInsertAfter" argument/field means the window that will be
directly above after the change, not the window that will be
directly below. MSDN says "precedes" for SetWindowPos(), but
WINDOWPOS documentation is more precise: this is the window
behind which the affected window will be placed. Apparently,
Z-axis goes back-to-front.
Therefore, logging should be reworded correctly.
2) When we switch away from the application and then switch back
to a transient window, we need to bring up its transient-owner
(and its transient-owner's owner and so forth) as well,
otherwise our transient (modal) window might be transient for
something that might not be visible.
3) When we bring up a window, we should bring all of its children
(popup windows) on top of it.
Because Windows doesn't provide a function to bring one window
on top of the other, we have to work around this by calling
SetWindowPos() twice, swapping the windows between the calls.
Make GtkMenuBar use a box as well,
and let GtkMenuShell get the items
from GtkMenuBar and GtkMenu via
a vfunc. Use that to fix the keynav
implementation in GtkMenuShell.
