These tests may have some assumptions on reasonable window manager
behaviour. For now, we just test that the default size of the
window ends up as the allocated size of the content. This test
currently fails with client-side decorations, because we are
not properly discriminating between overall window size and
content size.
There is currently no Wayland protocol for providing presentation
timestamps or hints about when drawing will be presented onscreen.
However, by assuming the straightforward algorithm used by the
DRM backend to Weston, we can reverse engineer the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Combine duplicate code for creating and destroying surfaces.
To make the operation of the destroy() operation more obvious, the
destruction of the (fake) root window at display dispose time is
changed to not be a "foreign" destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Use wl_surface_frame() to get notification when the compositor paints
a frame, and use this to throttle drawing to the compositor's refresh
cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Lazily creating the cairo surface that backs a window when we
first paint to it means that the call to
gdk_wayland_window_attach_image() in
gdk_wayland_window_process_updates_recurse() wasn't working the
first time a window was painted.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
When exposing an area, we were individually damaging and committing
each rectangle, *before* drawing. Surprisingly, this almost worked.
Order things right and only commit once.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Cache the style contexts for the up and down panels, instead of recreating
them each time they are drawn or size requested. GtkSpinButtons were
many times slower to draw than other widgets because of the constant
style matching.
https://bugzilla.gnome.org/show_bug.cgi?id=698682
If a subclass (say a child of GtkButton) overrides the non-baseline
size request methods we need to call these, rather than the new
get_height_and_baseline_for_width method.
In order to handle this we make the default for this method to be
NULL, and instead check at runtime which method to call. If any
non-baseline vfunc has changed in a class but the baseline one
hasn't, then we can't use the baseline one.
We now report any baselines from the child, and allocate it.
Also, in the case of a baselign aligned child we ignore yscale/yalign
as that is not supportable.
Report a baseline based height and baseline whenever there
are children with ALIGN_BASELINE.
Assign baseline to childen in size_allocate. Either the one inherited
from the parent if set, or otherwise calculate one based on any
ALIGN_BASELINE children.
This modifies the size machinery in order to allow baseline support.
We add a new widget vfunc get_preferred_height_and_baseline_for_width
which queries the normal height_for_width (or non-for-width if width
is -1) and additionally returns optional (-1 means "no baseline")
baselines for the minimal and natural heights.
We also add a new gtk_widget_size_allocate_with_baseline() which
baseline-aware containers can use to allocate children with a specific
baseline, either one inherited from the parent, or one introduced due
to requested baseline alignment in the container
itself. size_allocate_with_baseline() works just like a normal size
allocation, except the baseline gets recorded so that the child can
access it via gtk_widget_get_allocated_baseline() when it aligns
itself.
There are also adjust_baseline_request/allocation similar to the
allocation adjustment, and we extend the size request cache to also
store the baselines.
