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
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 Red Hat Inc.
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library 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
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
2018-10-19 03:15:54 -04:00
|
|
|
/**
|
|
|
|
* SECTION:meta-renderer-view
|
|
|
|
* @title: MetaRendererView
|
|
|
|
* @short_description: Renders (a part of) the global stage.
|
|
|
|
*
|
|
|
|
* A MetaRendererView object is responsible for rendering (a part of) the
|
|
|
|
* global stage, or more precisely: the part that matches what can be seen on a
|
|
|
|
* #MetaLogicalMonitor. By splitting up the rendering into different parts and
|
|
|
|
* attaching it to a #MetaLogicalMonitor, we can do the rendering so that each
|
|
|
|
* renderer view is responsible for applying the right #MetaMonitorTransform
|
|
|
|
* and the right scaling.
|
|
|
|
*/
|
|
|
|
|
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 "config.h"
|
|
|
|
|
|
|
|
#include "backends/meta-renderer-view.h"
|
|
|
|
|
2020-04-01 05:13:22 -04:00
|
|
|
#include "backends/meta-crtc.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-renderer.h"
|
|
|
|
#include "clutter/clutter-mutter.h"
|
2020-05-05 13:05:36 -04:00
|
|
|
#include "compositor/region-utils.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
|
|
|
|
2016-06-08 05:05:31 -04:00
|
|
|
enum
|
|
|
|
{
|
|
|
|
PROP_0,
|
|
|
|
|
2016-07-31 21:05:44 -04:00
|
|
|
PROP_TRANSFORM,
|
2020-04-01 05:13:22 -04:00
|
|
|
PROP_CRTC,
|
2016-06-08 05:05:31 -04:00
|
|
|
|
|
|
|
PROP_LAST
|
|
|
|
};
|
|
|
|
|
|
|
|
static GParamSpec *obj_props[PROP_LAST];
|
|
|
|
|
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
|
|
|
struct _MetaRendererView
|
|
|
|
{
|
2021-05-10 15:15:53 -04:00
|
|
|
MetaStageView parent;
|
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-07-31 21:05:44 -04:00
|
|
|
MetaMonitorTransform transform;
|
2020-04-01 05:13:22 -04:00
|
|
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
|
|
|
G_DEFINE_TYPE (MetaRendererView, meta_renderer_view,
|
2021-05-10 15:15:53 -04:00
|
|
|
META_TYPE_STAGE_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
|
|
|
|
2017-03-17 04:38:36 -04:00
|
|
|
MetaMonitorTransform
|
|
|
|
meta_renderer_view_get_transform (MetaRendererView *view)
|
|
|
|
{
|
|
|
|
return view->transform;
|
|
|
|
}
|
|
|
|
|
2020-04-01 05:13:22 -04:00
|
|
|
MetaCrtc *
|
|
|
|
meta_renderer_view_get_crtc (MetaRendererView *view)
|
|
|
|
{
|
|
|
|
return view->crtc;
|
|
|
|
}
|
|
|
|
|
2016-07-31 21:05:44 -04:00
|
|
|
static void
|
2020-09-11 14:57:28 -04:00
|
|
|
meta_renderer_view_get_offscreen_transformation_matrix (ClutterStageView *view,
|
|
|
|
graphene_matrix_t *matrix)
|
2016-07-31 21:05:44 -04:00
|
|
|
{
|
|
|
|
MetaRendererView *renderer_view = META_RENDERER_VIEW (view);
|
|
|
|
|
2020-09-11 18:12:06 -04:00
|
|
|
graphene_matrix_init_identity (matrix);
|
2016-07-31 21:05:44 -04:00
|
|
|
|
|
|
|
switch (renderer_view->transform)
|
|
|
|
{
|
|
|
|
case META_MONITOR_TRANSFORM_NORMAL:
|
|
|
|
break;
|
|
|
|
case META_MONITOR_TRANSFORM_90:
|
2020-09-11 18:12:06 -04:00
|
|
|
graphene_matrix_translate (matrix, &GRAPHENE_POINT3D_INIT (0, -1, 0));
|
|
|
|
graphene_matrix_rotate (matrix, 90, graphene_vec3_z_axis ());
|
2016-07-31 21:05:44 -04:00
|
|
|
break;
|
|
|
|
case META_MONITOR_TRANSFORM_180:
|
2020-09-11 18:12:06 -04:00
|
|
|
graphene_matrix_translate (matrix, &GRAPHENE_POINT3D_INIT (-1, -1, 0));
|
|
|
|
graphene_matrix_rotate (matrix, 180, graphene_vec3_z_axis ());
|
2016-07-31 21:05:44 -04:00
|
|
|
break;
|
|
|
|
case META_MONITOR_TRANSFORM_270:
|
2020-09-11 18:12:06 -04:00
|
|
|
graphene_matrix_translate (matrix, &GRAPHENE_POINT3D_INIT (-1, 0, 0));
|
|
|
|
graphene_matrix_rotate (matrix, 270, graphene_vec3_z_axis ());
|
2016-07-31 21:05:44 -04:00
|
|
|
break;
|
|
|
|
case META_MONITOR_TRANSFORM_FLIPPED:
|
2020-09-11 18:12:06 -04:00
|
|
|
graphene_matrix_translate (matrix, &GRAPHENE_POINT3D_INIT (-1, 0, 0));
|
|
|
|
graphene_matrix_scale (matrix, -1, 1, 1);
|
2016-07-31 21:05:44 -04:00
|
|
|
break;
|
|
|
|
case META_MONITOR_TRANSFORM_FLIPPED_90:
|
2020-09-11 18:12:06 -04:00
|
|
|
graphene_matrix_rotate (matrix, 90, graphene_vec3_z_axis ());
|
|
|
|
graphene_matrix_scale (matrix, -1, 1, 1);
|
2016-07-31 21:05:44 -04:00
|
|
|
break;
|
|
|
|
case META_MONITOR_TRANSFORM_FLIPPED_180:
|
2020-09-11 18:12:06 -04:00
|
|
|
graphene_matrix_translate (matrix, &GRAPHENE_POINT3D_INIT (0, -1, 0));
|
|
|
|
graphene_matrix_rotate (matrix, 180, graphene_vec3_z_axis ());
|
|
|
|
graphene_matrix_scale (matrix, -1, 1, 1);
|
2016-07-31 21:05:44 -04:00
|
|
|
break;
|
|
|
|
case META_MONITOR_TRANSFORM_FLIPPED_270:
|
2020-09-11 18:12:06 -04:00
|
|
|
graphene_matrix_translate (matrix, &GRAPHENE_POINT3D_INIT (-1, -1, 0));
|
|
|
|
graphene_matrix_rotate (matrix, 270, graphene_vec3_z_axis ());
|
|
|
|
graphene_matrix_scale (matrix, -1, 1, 1);
|
2016-07-31 21:05:44 -04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_renderer_view_setup_offscreen_blit_pipeline (ClutterStageView *view,
|
|
|
|
CoglPipeline *pipeline)
|
|
|
|
{
|
2020-09-11 14:57:28 -04:00
|
|
|
graphene_matrix_t matrix;
|
2016-07-31 21:05:44 -04:00
|
|
|
|
|
|
|
meta_renderer_view_get_offscreen_transformation_matrix (view, &matrix);
|
|
|
|
cogl_pipeline_set_layer_matrix (pipeline, 0, &matrix);
|
|
|
|
}
|
|
|
|
|
2020-05-05 13:05:36 -04:00
|
|
|
static void
|
|
|
|
meta_renderer_view_transform_rect_to_onscreen (ClutterStageView *view,
|
|
|
|
const cairo_rectangle_int_t *src_rect,
|
|
|
|
int dst_width,
|
|
|
|
int dst_height,
|
|
|
|
cairo_rectangle_int_t *dst_rect)
|
|
|
|
{
|
|
|
|
MetaRendererView *renderer_view = META_RENDERER_VIEW (view);
|
|
|
|
|
|
|
|
return meta_rectangle_transform (src_rect,
|
2022-06-14 12:42:13 -04:00
|
|
|
renderer_view->transform,
|
2020-05-05 13:05:36 -04:00
|
|
|
dst_width,
|
|
|
|
dst_height,
|
|
|
|
dst_rect);
|
|
|
|
}
|
|
|
|
|
2016-07-31 21:05:44 -04:00
|
|
|
static void
|
|
|
|
meta_renderer_view_set_transform (MetaRendererView *view,
|
|
|
|
MetaMonitorTransform transform)
|
|
|
|
{
|
|
|
|
if (view->transform == transform)
|
|
|
|
return;
|
|
|
|
|
|
|
|
view->transform = transform;
|
|
|
|
clutter_stage_view_invalidate_offscreen_blit_pipeline (CLUTTER_STAGE_VIEW (view));
|
|
|
|
}
|
|
|
|
|
2016-06-08 05:05:31 -04:00
|
|
|
static void
|
|
|
|
meta_renderer_view_get_property (GObject *object,
|
|
|
|
guint prop_id,
|
|
|
|
GValue *value,
|
|
|
|
GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
MetaRendererView *view = META_RENDERER_VIEW (object);
|
|
|
|
|
|
|
|
switch (prop_id)
|
|
|
|
{
|
2016-07-31 21:05:44 -04:00
|
|
|
case PROP_TRANSFORM:
|
|
|
|
g_value_set_uint (value, view->transform);
|
|
|
|
break;
|
2020-04-01 05:13:22 -04:00
|
|
|
case PROP_CRTC:
|
|
|
|
g_value_set_object (value, view->crtc);
|
|
|
|
break;
|
2016-06-08 05:05:31 -04:00
|
|
|
default:
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_renderer_view_set_property (GObject *object,
|
|
|
|
guint prop_id,
|
|
|
|
const GValue *value,
|
|
|
|
GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
MetaRendererView *view = META_RENDERER_VIEW (object);
|
|
|
|
|
|
|
|
switch (prop_id)
|
|
|
|
{
|
2016-07-31 21:05:44 -04:00
|
|
|
case PROP_TRANSFORM:
|
|
|
|
meta_renderer_view_set_transform (view, g_value_get_uint (value));
|
|
|
|
break;
|
2020-04-01 05:13:22 -04:00
|
|
|
case PROP_CRTC:
|
|
|
|
view->crtc = g_value_get_object (value);
|
|
|
|
break;
|
2016-06-08 05:05:31 -04:00
|
|
|
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
|
|
|
|
meta_renderer_view_init (MetaRendererView *view)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_renderer_view_class_init (MetaRendererViewClass *klass)
|
|
|
|
{
|
2016-06-08 05:05:31 -04:00
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (klass);
|
2016-07-31 21:05:44 -04:00
|
|
|
ClutterStageViewClass *view_class = CLUTTER_STAGE_VIEW_CLASS (klass);
|
|
|
|
|
|
|
|
view_class->setup_offscreen_blit_pipeline =
|
|
|
|
meta_renderer_view_setup_offscreen_blit_pipeline;
|
|
|
|
view_class->get_offscreen_transformation_matrix =
|
|
|
|
meta_renderer_view_get_offscreen_transformation_matrix;
|
2020-05-05 13:05:36 -04:00
|
|
|
view_class->transform_rect_to_onscreen =
|
|
|
|
meta_renderer_view_transform_rect_to_onscreen;
|
2016-06-08 05:05:31 -04:00
|
|
|
|
|
|
|
object_class->get_property = meta_renderer_view_get_property;
|
|
|
|
object_class->set_property = meta_renderer_view_set_property;
|
|
|
|
|
2016-07-31 21:05:44 -04:00
|
|
|
obj_props[PROP_TRANSFORM] =
|
|
|
|
g_param_spec_uint ("transform",
|
|
|
|
"Transform",
|
|
|
|
"Transform to apply to the view",
|
|
|
|
META_MONITOR_TRANSFORM_NORMAL,
|
|
|
|
META_MONITOR_TRANSFORM_FLIPPED_270,
|
|
|
|
META_MONITOR_TRANSFORM_NORMAL,
|
|
|
|
G_PARAM_READWRITE |
|
|
|
|
G_PARAM_CONSTRUCT_ONLY |
|
|
|
|
G_PARAM_STATIC_STRINGS);
|
2016-06-08 05:05:31 -04:00
|
|
|
|
2020-04-01 05:13:22 -04:00
|
|
|
obj_props[PROP_CRTC] =
|
|
|
|
g_param_spec_object ("crtc",
|
|
|
|
"MetaCrtc",
|
|
|
|
"MetaCrtc",
|
|
|
|
META_TYPE_CRTC,
|
|
|
|
G_PARAM_READWRITE |
|
|
|
|
G_PARAM_CONSTRUCT_ONLY |
|
|
|
|
G_PARAM_STATIC_STRINGS);
|
|
|
|
|
2016-06-08 05:05:31 -04:00
|
|
|
g_object_class_install_properties (object_class, PROP_LAST, obj_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
|
|
|
}
|