Commit Graph

6 Commits

Author SHA1 Message Date
Jonas Ådahl
9ed463b488 renderer-view: Keep track of what CRTC it is associated with
For the nested and native backend, it'll point to the CRTC it was
created for. On the X11 CM backend, it'll be NULL, as there is only a
single global stage view.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-07-02 19:36:50 +02:00
Jonas Ådahl
1c98f01a65 renderer-native: Draw stage separately per CRTC
Prior to this commit the stage was drawn separately for each logical
monitor. This allowed to draw different parts of the stage with
different transformations, e.g. with a different viewport to implement
HiDPI support.

Go even further and have one view per CRTC. This causes the stage to
e.g. draw two mirrored monitors twice, instead of using the same
framebuffer on both. This enables us to do two things: one is to support
tiled monitors and monitor mirroring using the EGLStreams backend; the
other is that it'll enable us to tie rendering directly to the CRTC it
will render for. It is also a requirement for rendering being affected
by CRTC state, such as gamma.

It'll be possible to still inhibit re-drawing of the same content
twice, but it should be implemented differently, so that it will still
be possible to implement features requiring the CRTC split.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
2020-02-25 18:39:51 +01:00
Jonas Ådahl
8a29c51b73 renderer-view: Add view transform getter
This will later be used by the nested backend to emulate per CRTC
rendering.

https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-07 22:30:49 +08:00
Jonas Ådahl
842ff5d6aa Rename MetaMonitorInfo MetaLogicalMonitor
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.

https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-25 16:28:51 +08:00
Jonas Ådahl
aecd98b847 backends/native: Support drawing onto multiple onscreen framebuffers
Add support for drawing the stage using multiple stage views, where
each stage view has its own onscreen framebuffer.

https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-07-20 14:23:48 +08:00
Jonas Ådahl
566c28bdaf 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-07-20 14:23:48 +08:00