GNOME Bugzilla – Bug 745076
Various DPI and OpenGL related fixes in the Wayland backend
Last modified: 2015-02-25 01:27:58 UTC
These patches fixes some issues related to HiDPI rendering for SHM and OpenGL windows. The last patch however is purely a memory optimization.
Created attachment 297747 [details] [review] wayland: Don't ever try to set surface buffer scale when not supported If the compositor is too old for handling surface buffer scales, never tyr to set change it. This will effectively always leave it to its initial state, i.e. 1.
Created attachment 297748 [details] [review] wayland: Properly support changing of surface scale When the preferred surface scale changes, for example when entering a wl_output with a higher scale than any previous entered output, recreate the shm surface and redraw the window content with the new window scale. Before this patch, the internal scale would be changed, but the shm surface would not be recreated given the new scale, i.e. we'd attach a buffer for a different scale than wl_surface.set_scale specified.
Created attachment 297749 [details] [review] wayland: Scale up wl_egl_window according to window scale In order to support window scales for EGL windows, resize the wl_egl_window to the window dimension multiplied with the window scale, just as with SHM window buffers.
Created attachment 297750 [details] [review] wayland: Don't allocate a full size SHM buffer when drawing using OpenGL Before this patch, we'd always allocate a full size SHM buffer via the wl_shm_pool, even though it would never be used. Instead allocate a logical 1x1 cairo image surface.
Review of attachment 297747 [details] [review]: Looks good.
Review of attachment 297748 [details] [review]: Looks okay.
Review of attachment 297749 [details] [review]: Looks okay.
Review of attachment 297750 [details] [review]: Looks okay.
I did a review and everything seemed okay, but you probably also want a final ACK from a GDK Wayland developer or mclasen.
Is that how OpenGL windows should work? I noticed that the gtk3-demo OpenGL sample renders differently given the window scale. To reproduce, apply the xdg-shell v5 patches to weston, add the following lines to ~/.config/weston.ini: [output] name=X1 scale=1 [output] name=X2 scale=2 then start the OpenGL sample in gtk3-demo on the X1 output and drag it so that any part of the GTK+ OpenGL window overlaps with the X2 output. It made me wonder how HiDPI how was meant to work for OpenGL windows. I couldn't see any mention of scales in the documentation.
Attachment 297747 [details] pushed as a70b478 - wayland: Don't ever try to set surface buffer scale when not supported Attachment 297748 [details] pushed as 56c9eac - wayland: Properly support changing of surface scale Attachment 297749 [details] pushed as aa81262 - wayland: Scale up wl_egl_window according to window scale Attachment 297750 [details] pushed as f13157f - wayland: Don't allocate a full size SHM buffer when drawing using OpenGL