After discussing with Kristian Høgsberg it seems that the semantics of
wl_egl_window_resize is meant to be that if nothing has been drawn to
the framebuffer since the last swap then the resize will take effect
immediately. Cogl was previously always delaying the call to
wl_egl_window_resize until the next swap. That meant that if you
wanted to resize the surface you would have to call
cogl_wayland_onscreen_resize and then redundantly draw a frame at the
old size so that you can swap to get the resize to occur before
drawing again at the right size. Typically an application would decide
to resize at the start of its paint sequence so it should be able to
just resize immediately.
In current Mesa master it seems that there is a bug which means that
it won't actually delay a resize that is done mid-scene and instead it
will just discard what came before. To get consistent behaviour in
Cogl, the code to delay the call to wl_egl_window_resize is still used
if it determines that the buffer is dirty. There is an existing
_cogl_framebuffer_mark_mid_scene call which was being used to track
when the framebuffer becomes dirty since the last clear. This function
is now also used to track a new flag to track whether something has
been drawn since the last swap. It is called ‘mid_scene’ under the
assumption that this may also be useful for other things later.
cogl_framebuffer_clear has been slightly altered to always call
_cogl_framebuffer_mark_mid_scene even if it determines that it doesn't
need to clear because the framebuffer should still be considered to be
in the middle of a scene. Adding a quad to the journal now also begins
the scene.
This also fixes a potential bug where it looks like pending_dx/dy were
never cleared so they would always be accumulated even after the
resize is flushed.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 945689a62903990a20abb87a85d2c96eb3985fe7)
45e18e0fb7