Ugh. So in the fullscreen case, we need to make sure to specify that
it's a MOVE_ACTION so that we move to the saved position, but we
can't do that in the resizing case since we need to use the resized
rectangle.
The flags are really hurting us here. Perhaps we should make it the
client's responsibility to specify a complete rectangle which we
could resize to; then the weird-o logic would be self-contained in
each front-end.
I'm not convinced this covers all cases, especially when we could have
a dangling weird state pointer, but it fixes our existing two testcases.
For gravity-based resizing, we need to make sure that the requested
rectangle has the proper x/y position given by the gravity resize,
rather than the bogus root_x_nw / root_y_nw parameter.
Make the test for this more explicit.
When an actor carrying canvas content is repainted, it will currently reupload
the data from the buffer to a texture. While this is not a performance problem
on a desktop, some mobile environments take a big performance hit. This
change tracks data changes and only recreates the texture if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=729144
This can happen when we dpms off the output or when login1 takes away
drm master status from our drm fd. In either case, we need to call
the swap notify handler so that the compositor dosn't get stuck waiting
for that notification. The compositor should stop repainting shortly in
both cases, as it's either going into dpms off mode or vt switching away.
https://bugzilla.gnome.org/show_bug.cgi?id=728979
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This environment variable predates the reliable platform detection in mesa
and typically just causes crashes when the specified platform doesn't
match what's passed in. Aside from being unecessary and problematic
it also leaks into the GNOME session, preventing clients from
automatically detecting the wayland platform.
https://bugzilla.gnome.org/show_bug.cgi?id=728978
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Restoring the position in our move_resize_internal implementation
is too late. We need to do it at ack-time, before we hand off the
new position to the constraints code.
With our surface_mapped strategy, implement_showing might not
change whether the window has been shown or not, and thus we
might end up clearing pending_compositor_effect before the window
is mapped.
Only clear pending_compositor_effect when the effect has actually
been used.
When an actor carrying canvas content is repainted, it will currently reupload
the data from the buffer to a texture. While this is not a performance problem
on a desktop, some mobile environments take a big performance hit. This
change tracks data changes and only recreates the texture if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=729144
For the server-initiated resize case, like unmaximize or some forms
of tiling, we dropped the x/y of the server-assigned rectangle on the
floor, which meant the surface didn't move to where it needed to be in
that case. Now, save it internally, and combine it with the dx/dy passed
in during attaches to figure out where we actually need to be.
Make sure to only use it for when we send out a configure notify. We
should use the passed in rectangle for other scenarios, like a
client-initiated resize.
This fixes incorrect surface placement after unmaximization.
For the server-initiated resize case, like unmaximize or some forms
of tiling, we dropped the x/y of the server-assigned rectangle on the
floor, which meant the surface didn't move to where it needed to be in
that case. Now, save it internally, and combine it with the dx/dy passed
in during attaches to figure out where we actually need to be.
This fixes incorrect surface placement after unmaximization.
