2016-05-07 11:07:46 -04:00
|
|
|
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 Red Hat
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
|
|
|
* published by the Free Software Foundation; either version 2 of the
|
|
|
|
* License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2023-08-07 05:50:23 -04:00
|
|
|
* along with this program; if not, see <http://www.gnu.org/licenses/>.
|
2016-05-07 11:07:46 -04:00
|
|
|
*
|
|
|
|
* Written by:
|
|
|
|
* Jonas Ådahl <jadahl@gmail.com>
|
|
|
|
*/
|
|
|
|
|
2018-10-19 03:15:54 -04:00
|
|
|
/**
|
2023-03-28 10:35:11 -04:00
|
|
|
* MetaRenderer:
|
2023-05-23 14:25:54 -04:00
|
|
|
*
|
2023-03-28 10:35:11 -04:00
|
|
|
* Keeps track of the different renderer views.
|
2018-10-19 03:15:54 -04:00
|
|
|
*
|
|
|
|
* A MetaRenderer object has 2 functions:
|
|
|
|
*
|
2023-03-28 10:35:11 -04:00
|
|
|
* 1) Keeping a list of `MetaRendererView`s, each responsible for
|
2018-10-19 03:15:54 -04:00
|
|
|
* rendering a part of the stage, corresponding to each #MetaLogicalMonitor. It
|
|
|
|
* keeps track of this list by querying the list of logical monitors in the
|
|
|
|
* #MetaBackend's #MetaMonitorManager, and creating a renderer view for each
|
|
|
|
* logical monitor it encounters.
|
|
|
|
*
|
|
|
|
* 2) Creating and setting up an appropriate #CoglRenderer. For example, a
|
|
|
|
* #MetaRenderer might call cogl_renderer_set_custom_winsys() to tie the
|
|
|
|
* backend-specific mechanisms into Cogl.
|
|
|
|
*/
|
|
|
|
|
2016-05-07 11:07:46 -04:00
|
|
|
#include "config.h"
|
|
|
|
|
2018-07-10 04:36:24 -04:00
|
|
|
#include "backends/meta-renderer.h"
|
|
|
|
|
2016-05-07 11:07:46 -04:00
|
|
|
#include <glib-object.h>
|
|
|
|
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
#include "backends/meta-backend-private.h"
|
2020-01-17 15:08:02 -05:00
|
|
|
#include "backends/meta-logical-monitor.h"
|
2016-05-07 11:07:46 -04:00
|
|
|
|
2019-10-01 05:51:53 -04:00
|
|
|
enum
|
|
|
|
{
|
|
|
|
PROP_0,
|
|
|
|
|
|
|
|
PROP_BACKEND,
|
|
|
|
|
|
|
|
N_PROPS
|
|
|
|
};
|
|
|
|
|
|
|
|
static GParamSpec *obj_props[N_PROPS];
|
|
|
|
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
typedef struct _MetaRendererPrivate
|
|
|
|
{
|
2019-10-01 05:51:53 -04:00
|
|
|
MetaBackend *backend;
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
GList *views;
|
clutter: Paint views with individual frame clocks
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:27:56 -04:00
|
|
|
gboolean is_paused;
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
} MetaRendererPrivate;
|
|
|
|
|
|
|
|
G_DEFINE_TYPE_WITH_PRIVATE (MetaRenderer, meta_renderer, G_TYPE_OBJECT)
|
2016-05-07 11:07:46 -04:00
|
|
|
|
2019-10-01 05:51:53 -04:00
|
|
|
MetaBackend *
|
|
|
|
meta_renderer_get_backend (MetaRenderer *renderer)
|
|
|
|
{
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
|
|
|
|
return priv->backend;
|
|
|
|
}
|
|
|
|
|
2018-10-19 03:15:54 -04:00
|
|
|
/**
|
|
|
|
* meta_renderer_create_cogl_renderer:
|
|
|
|
* @renderer: a #MetaRenderer object
|
|
|
|
*
|
|
|
|
* Creates a #CoglRenderer that is appropriate for a certain backend. For
|
|
|
|
* example, a #MetaRenderer might call cogl_renderer_set_custom_winsys() to tie
|
|
|
|
* the backend-specific mechanisms (such as swapBuffers and vsync) into Cogl.
|
|
|
|
*
|
|
|
|
* Returns: (transfer full): a newly made #CoglRenderer.
|
|
|
|
*/
|
2016-05-08 21:59:54 -04:00
|
|
|
CoglRenderer *
|
|
|
|
meta_renderer_create_cogl_renderer (MetaRenderer *renderer)
|
|
|
|
{
|
|
|
|
return META_RENDERER_GET_CLASS (renderer)->create_cogl_renderer (renderer);
|
|
|
|
}
|
|
|
|
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
static MetaRendererView *
|
2016-11-25 01:31:38 -05:00
|
|
|
meta_renderer_create_view (MetaRenderer *renderer,
|
2020-01-17 15:08:02 -05:00
|
|
|
MetaLogicalMonitor *logical_monitor,
|
|
|
|
MetaOutput *output,
|
|
|
|
MetaCrtc *crtc)
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
{
|
|
|
|
return META_RENDERER_GET_CLASS (renderer)->create_view (renderer,
|
2020-01-17 15:08:02 -05:00
|
|
|
logical_monitor,
|
|
|
|
output,
|
|
|
|
crtc);
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
}
|
|
|
|
|
2018-10-19 03:15:54 -04:00
|
|
|
/**
|
|
|
|
* meta_renderer_rebuild_views:
|
|
|
|
* @renderer: a #MetaRenderer object
|
|
|
|
*
|
|
|
|
* Rebuilds the internal list of #MetaRendererView objects by querying the
|
|
|
|
* current #MetaBackend's #MetaMonitorManager.
|
|
|
|
*
|
|
|
|
* This also leads to the original list of monitors being unconditionally freed.
|
|
|
|
*/
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
void
|
|
|
|
meta_renderer_rebuild_views (MetaRenderer *renderer)
|
2019-06-19 14:57:14 -04:00
|
|
|
{
|
|
|
|
return META_RENDERER_GET_CLASS (renderer)->rebuild_views (renderer);
|
|
|
|
}
|
|
|
|
|
2020-01-17 15:08:02 -05:00
|
|
|
static void
|
|
|
|
create_crtc_view (MetaLogicalMonitor *logical_monitor,
|
|
|
|
MetaMonitor *monitor,
|
|
|
|
MetaOutput *output,
|
|
|
|
MetaCrtc *crtc,
|
|
|
|
gpointer user_data)
|
|
|
|
{
|
|
|
|
MetaRenderer *renderer = user_data;
|
|
|
|
MetaRendererView *view;
|
|
|
|
|
|
|
|
view = meta_renderer_create_view (renderer, logical_monitor, output, crtc);
|
2020-07-01 04:38:32 -04:00
|
|
|
meta_renderer_add_view (renderer, view);
|
2020-01-17 15:08:02 -05:00
|
|
|
}
|
|
|
|
|
2019-06-19 14:57:14 -04:00
|
|
|
static void
|
|
|
|
meta_renderer_real_rebuild_views (MetaRenderer *renderer)
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
{
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
2022-05-27 13:35:01 -04:00
|
|
|
MetaBackend *backend = priv->backend;
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
MetaMonitorManager *monitor_manager =
|
|
|
|
meta_backend_get_monitor_manager (backend);
|
2016-12-02 03:00:03 -05:00
|
|
|
GList *logical_monitors, *l;
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
|
2021-04-09 18:49:51 -04:00
|
|
|
g_clear_list (&priv->views, (GDestroyNotify) clutter_stage_view_destroy);
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
|
2016-11-25 01:31:38 -05:00
|
|
|
logical_monitors =
|
2016-12-02 03:00:03 -05:00
|
|
|
meta_monitor_manager_get_logical_monitors (monitor_manager);
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
|
2016-12-02 03:00:03 -05:00
|
|
|
for (l = logical_monitors; l; l = l->next)
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
{
|
2016-12-02 03:00:03 -05:00
|
|
|
MetaLogicalMonitor *logical_monitor = l->data;
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
|
2020-06-06 16:58:10 -04:00
|
|
|
if (meta_logical_monitor_is_primary (logical_monitor))
|
|
|
|
{
|
|
|
|
ClutterBackend *clutter_backend;
|
|
|
|
float scale;
|
|
|
|
|
|
|
|
clutter_backend = meta_backend_get_clutter_backend (backend);
|
2022-05-27 14:30:37 -04:00
|
|
|
scale = meta_backend_is_stage_views_scaled (backend)
|
2020-06-06 16:58:10 -04:00
|
|
|
? meta_logical_monitor_get_scale (logical_monitor)
|
|
|
|
: 1.f;
|
|
|
|
|
|
|
|
clutter_backend_set_fallback_resource_scale (clutter_backend, scale);
|
|
|
|
}
|
|
|
|
|
2020-01-17 15:08:02 -05:00
|
|
|
meta_logical_monitor_foreach_crtc (logical_monitor,
|
|
|
|
create_crtc_view,
|
|
|
|
renderer);
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-08 11:36:19 -04:00
|
|
|
MetaRendererView *
|
2020-04-01 05:14:46 -04:00
|
|
|
meta_renderer_get_view_for_crtc (MetaRenderer *renderer,
|
|
|
|
MetaCrtc *crtc)
|
|
|
|
{
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
for (l = priv->views; l; l = l->next)
|
|
|
|
{
|
|
|
|
MetaRendererView *view = l->data;
|
|
|
|
|
|
|
|
if (meta_renderer_view_get_crtc (view) == crtc)
|
|
|
|
return view;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
typedef struct _CollectViewsData
|
|
|
|
{
|
|
|
|
MetaRenderer *renderer;
|
|
|
|
GList *out_views;
|
|
|
|
} CollectViewsData;
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
collect_views (MetaMonitor *monitor,
|
|
|
|
MetaMonitorMode *mode,
|
|
|
|
MetaMonitorCrtcMode *monitor_crtc_mode,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
CollectViewsData *data = user_data;
|
|
|
|
MetaCrtc *crtc;
|
|
|
|
MetaRendererView *view;
|
|
|
|
|
|
|
|
crtc = meta_output_get_assigned_crtc (monitor_crtc_mode->output);
|
|
|
|
view = meta_renderer_get_view_for_crtc (data->renderer, crtc);
|
|
|
|
if (!g_list_find (data->out_views, view))
|
|
|
|
data->out_views = g_list_prepend (data->out_views, view);
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GList *
|
|
|
|
meta_renderer_real_get_views_for_monitor (MetaRenderer *renderer,
|
|
|
|
MetaMonitor *monitor)
|
|
|
|
{
|
|
|
|
CollectViewsData data = { 0 };
|
|
|
|
MetaMonitorMode *monitor_mode;
|
|
|
|
|
|
|
|
data.renderer = renderer;
|
|
|
|
|
|
|
|
monitor_mode = meta_monitor_get_current_mode (monitor);
|
|
|
|
meta_monitor_mode_foreach_crtc (monitor, monitor_mode,
|
|
|
|
collect_views,
|
|
|
|
&data,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
return data.out_views;
|
|
|
|
}
|
|
|
|
|
|
|
|
GList *
|
|
|
|
meta_renderer_get_views_for_monitor (MetaRenderer *renderer,
|
|
|
|
MetaMonitor *monitor)
|
|
|
|
{
|
|
|
|
return META_RENDERER_GET_CLASS (renderer)->get_views_for_monitor (renderer,
|
|
|
|
monitor);
|
|
|
|
}
|
|
|
|
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
void
|
2020-05-12 02:50:54 -04:00
|
|
|
meta_renderer_add_view (MetaRenderer *renderer,
|
|
|
|
MetaRendererView *view)
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
{
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
|
2020-05-12 02:50:54 -04:00
|
|
|
priv->views = g_list_append (priv->views, view);
|
clutter: Paint views with individual frame clocks
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:27:56 -04:00
|
|
|
|
|
|
|
if (priv->is_paused)
|
|
|
|
{
|
|
|
|
ClutterFrameClock *frame_clock =
|
|
|
|
clutter_stage_view_get_frame_clock (CLUTTER_STAGE_VIEW (view));
|
|
|
|
|
|
|
|
clutter_frame_clock_inhibit (frame_clock);
|
|
|
|
}
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
}
|
|
|
|
|
2018-10-19 03:15:54 -04:00
|
|
|
/**
|
|
|
|
* meta_renderer_get_views:
|
|
|
|
* @renderer: a #MetaRenderer object
|
|
|
|
*
|
|
|
|
* Returns a list of #MetaRendererView objects, each dealing with a part of the
|
|
|
|
* stage.
|
|
|
|
*
|
2019-01-08 03:06:11 -05:00
|
|
|
* Returns: (transfer none) (element-type MetaRendererView): a list of
|
2018-10-19 03:15:54 -04:00
|
|
|
* #MetaRendererView objects.
|
|
|
|
*/
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
GList *
|
|
|
|
meta_renderer_get_views (MetaRenderer *renderer)
|
|
|
|
{
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
|
|
|
|
return priv->views;
|
|
|
|
}
|
|
|
|
|
clutter: Paint views with individual frame clocks
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:27:56 -04:00
|
|
|
void
|
|
|
|
meta_renderer_pause (MetaRenderer *renderer)
|
|
|
|
{
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
g_return_if_fail (!priv->is_paused);
|
|
|
|
priv->is_paused = TRUE;
|
|
|
|
|
|
|
|
for (l = priv->views; l; l = l->next)
|
|
|
|
{
|
|
|
|
ClutterStageView *stage_view = l->data;
|
|
|
|
ClutterFrameClock *frame_clock =
|
|
|
|
clutter_stage_view_get_frame_clock (stage_view);
|
|
|
|
|
|
|
|
clutter_frame_clock_inhibit (frame_clock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
meta_renderer_resume (MetaRenderer *renderer)
|
|
|
|
{
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
2022-12-20 06:12:10 -05:00
|
|
|
MetaRendererClass *klass = META_RENDERER_GET_CLASS (renderer);
|
clutter: Paint views with individual frame clocks
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:27:56 -04:00
|
|
|
GList *l;
|
|
|
|
|
|
|
|
g_return_if_fail (priv->is_paused);
|
|
|
|
priv->is_paused = FALSE;
|
|
|
|
|
|
|
|
for (l = priv->views; l; l = l->next)
|
|
|
|
{
|
|
|
|
ClutterStageView *stage_view = l->data;
|
|
|
|
ClutterFrameClock *frame_clock =
|
|
|
|
clutter_stage_view_get_frame_clock (stage_view);
|
|
|
|
|
|
|
|
clutter_frame_clock_uninhibit (frame_clock);
|
|
|
|
}
|
2022-12-20 06:12:10 -05:00
|
|
|
|
|
|
|
if (klass->resume)
|
|
|
|
klass->resume (renderer);
|
clutter: Paint views with individual frame clocks
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:27:56 -04:00
|
|
|
}
|
|
|
|
|
2019-10-01 05:53:57 -04:00
|
|
|
gboolean
|
|
|
|
meta_renderer_is_hardware_accelerated (MetaRenderer *renderer)
|
|
|
|
{
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
MetaBackend *backend = priv->backend;
|
|
|
|
ClutterBackend *clutter_backend = meta_backend_get_clutter_backend (backend);
|
|
|
|
CoglContext *cogl_context =
|
|
|
|
clutter_backend_get_cogl_context (clutter_backend);
|
|
|
|
|
2020-06-17 18:42:53 -04:00
|
|
|
return cogl_context_is_hardware_accelerated (cogl_context);
|
2019-10-01 05:53:57 -04:00
|
|
|
}
|
|
|
|
|
2019-10-01 05:51:53 -04:00
|
|
|
static void
|
|
|
|
meta_renderer_get_property (GObject *object,
|
|
|
|
guint prop_id,
|
|
|
|
GValue *value,
|
|
|
|
GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
MetaRenderer *renderer = META_RENDERER (object);
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
|
|
|
|
switch (prop_id)
|
|
|
|
{
|
|
|
|
case PROP_BACKEND:
|
|
|
|
g_value_set_object (value, priv->backend);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_renderer_set_property (GObject *object,
|
|
|
|
guint prop_id,
|
|
|
|
const GValue *value,
|
|
|
|
GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
MetaRenderer *renderer = META_RENDERER (object);
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
|
|
|
|
switch (prop_id)
|
|
|
|
{
|
|
|
|
case PROP_BACKEND:
|
|
|
|
priv->backend = g_value_get_object (value);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
static void
|
2021-04-09 18:50:30 -04:00
|
|
|
meta_renderer_dispose (GObject *object)
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
{
|
|
|
|
MetaRenderer *renderer = META_RENDERER (object);
|
|
|
|
MetaRendererPrivate *priv = meta_renderer_get_instance_private (renderer);
|
|
|
|
|
2021-04-09 18:49:51 -04:00
|
|
|
g_clear_list (&priv->views, g_object_unref);
|
2020-01-22 14:47:15 -05:00
|
|
|
|
2021-04-09 18:50:30 -04:00
|
|
|
G_OBJECT_CLASS (meta_renderer_parent_class)->dispose (object);
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
}
|
|
|
|
|
2016-05-07 11:07:46 -04:00
|
|
|
static void
|
|
|
|
meta_renderer_init (MetaRenderer *renderer)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_renderer_class_init (MetaRendererClass *klass)
|
|
|
|
{
|
Introduce regional stage rendering
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-26 23:09:24 -04:00
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (klass);
|
|
|
|
|
2019-10-01 05:51:53 -04:00
|
|
|
object_class->get_property = meta_renderer_get_property;
|
|
|
|
object_class->set_property = meta_renderer_set_property;
|
2021-04-09 18:50:30 -04:00
|
|
|
object_class->dispose = meta_renderer_dispose;
|
2019-06-19 14:57:14 -04:00
|
|
|
|
|
|
|
klass->rebuild_views = meta_renderer_real_rebuild_views;
|
2020-04-01 05:14:46 -04:00
|
|
|
klass->get_views_for_monitor = meta_renderer_real_get_views_for_monitor;
|
2019-10-01 05:51:53 -04:00
|
|
|
|
|
|
|
obj_props[PROP_BACKEND] =
|
2023-06-28 08:02:43 -04:00
|
|
|
g_param_spec_object ("backend", NULL, NULL,
|
2019-10-01 05:51:53 -04:00
|
|
|
META_TYPE_BACKEND,
|
|
|
|
G_PARAM_READWRITE |
|
|
|
|
G_PARAM_CONSTRUCT_ONLY |
|
|
|
|
G_PARAM_STATIC_STRINGS);
|
|
|
|
g_object_class_install_properties (object_class, N_PROPS, obj_props);
|
2016-05-07 11:07:46 -04:00
|
|
|
}
|