Quelle WindowSurfaceWaylandMultiBuffer.cpp
Sprache: C
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- * * This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
Every rendering thread (main thread, compositor thread) contains its own nsWaylandDisplay object connected to Wayland compositor (Mutter, Weston, etc.)
WindowSurfaceWayland implements WindowSurface class and draws nsWindow by WindowSurface interface (Lock, Commit) to screen through nsWaylandDisplay.
Is our connection to Wayland display server, holds our display connection (wl_display) and event queue (wl_event_queue).
nsWaylandDisplay is created for every thread which sends data to Wayland compositor. Wayland events for main thread is served by default Gtk+ loop, for other threads (compositor) we must create wl_event_queue and run event loop.
WindowSurfaceWayland
Is a Wayland implementation of WindowSurface class for WindowSurfaceProvider, we implement Lock() and Commit() interfaces from WindowSurface for actual drawing.
One WindowSurfaceWayland draws one nsWindow so those are tied 1:1. At Wayland level it holds one wl_surface object.
To perform visualiation of nsWindow, WindowSurfaceWayland contains one wl_surface and two wl_buffer objects (owned by WaylandBufferSHM) 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.
When there's no wl_buffer available for drawing (all wl_buffers are locked in compositor for instance) we store the drawing to WindowImageSurface object and draw later when wl_buffer becomes available or discard the WindowImageSurface cache when whole screen is invalidated.
WaylandBufferSHM
Is a class which provides a wl_buffer for drawing. Wl_buffer is a main Wayland object with actual graphics data. Wl_buffer basically represent one complete window screen. When double buffering is involved every window (GdkWindow for instance) utilises two wl_buffers which are cycled. One is filed with data by application and one is rendered by compositor.
WaylandBufferSHM is implemented by shared memory (shm). It owns wl_buffer object, owns WaylandShmPool (which provides the shared memory) and ties them together.
WaylandShmPool
WaylandShmPool acts as a manager of shared memory for WaylandBufferSHM. Allocates it, holds reference to it and releases it.
We allocate shared memory (shm) by mmap(..., MAP_SHARED,...) as an interface between us and wayland compositor. We draw our graphics data to the shm and handle to wayland compositor by WaylandBufferSHM/WindowSurfaceWayland (wl_buffer/wl_surface).
*/
bool WindowSurfaceWaylandMB::MaybeUpdateWindowSize() { // We want to get window size from compositor widget as it matches window // size used by parent RenderCompositorSWGL rendrer. // For main thread rendering mCompositorWidget is not available so get // window size directly from nsWindow.
LayoutDeviceIntSize newWindowSize = mCompositorWidget
? mCompositorWidget->GetClientSize()
: mWindow->GetClientSize(); if (mWindowSize != newWindowSize) {
mWindowSize = newWindowSize; returntrue;
} returnfalse;
}
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung ist noch experimentell.