VSync on Wayland is a bit tricky as we can get only "last VSync" event signal with
CLOCK_MONOTONIC timestamp or none (if application is hidden/minimized).
That means we should draw a next frame at "last Vsync + frame delay" time and also
approximate next VSync event when we don't get any.
MozReview-Commit-ID: FI3Z4nkmDNK
When only a part of window is updated we need to clip that drawing.
We use image surface for that as WindowSurfaceX11Image does.
MozReview-Commit-ID: 13znE1ZszB8
We need to use scaling factor of the monitor on which application is actually positioned.
Previously we used ScreenHelperGTK::GetGTKMonitorScaleFactor() which use the first monitor.
This does not work on hidpi+normal dpi monitors setup.
The GetSystemFontInfo() cannot return scaled value of the font by default monitor
scale factor. We need to scale it in nsLookAndFeel::GetFontImpl
by aDevPixPerCSSPixel like implementation for Windows does.
We also need to check layout.css.devPixelsPerPx because we cannot
scale per monitor when this preference is set to positive number.
MozReview-Commit-ID: AwT2NvkEqvz
We need to use scaling factor of the monitor on which application is actually positioned.
Previously we used ScreenHelperGTK::GetGTKMonitorScaleFactor() which use the first monitor.
This does not work on hidpi+normal dpi monitors setup.
The GetSystemFontInfo() cannot return scaled value of the font by default monitor
scale factor. We need to scale it in nsLookAndFeel::GetFontImpl
by aDevPixPerCSSPixel like implementation for Windows does.
We also need to check layout.css.devPixelsPerPx because we cannot
scale per monitor when this preference is set to positive number.
MozReview-Commit-ID: AwT2NvkEqvz
WindowSurfaceWayland is Wayland implementation of WindowSurface class.
One WindowSurfaceWayland object manages drawing of one nsWindow so
those are tied 1:1. It implements base Lock() and Commit() interfaces
from WindowSurface. At Wayland side it represents one wl_surface object.
To perform visualiation of nsWindow, WindowSurfaceWayland contains
one wl_surface and two wl_buffer (by WindowBackBuffer) objects
(as we use double buffering). When nsWindow drawing is finished to
wl_buffer, the wl_buffer is attached to wl_surface and it's sent to
Wayland compositor.
MozReview-Commit-ID: 9NoamtF87e6
wl_buffer is a main Wayland object with graphics data. wl_buffer basically represent one complete window screen.
When double buffering is involved every window (GdkWindow in our case) utilises two wl_buffers which are cycled.
One is filed with data by application and one is rendered by compositor.
WindowBackBuffer class manages one wl_buffer. It owns wl_buffer object, owns WaylandShmPool (which provides shared memory)
and ties them together.
MozReview-Commit-ID: v8Hlezo7oD
We allocate shared memory (shm) by mmap(..., MAP_SHARED,...) as an interface between wayland based application
and wayland compositor. We draw our graphics data to the shm and handle to wayland compositor by wl_buffer/wl_surface.
WaylandShmPool acts as a manager of the allocated memory. Allocates it, holds reference to it and releases it.
MozReview-Commit-ID: CY6oEIl4Vxa
