Commit Graph

5 Commits

Author SHA1 Message Date
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
Carlos Garnacho
362ab781dd backends: Allow multiple "SW" cursor overlays on the stage
All the upper layers are prepared for multiple onscreen cursors, but
this. All MetaCursorRenderers created would poke the same internal
MetaOverlay in the stage.

This will lead to multiple cursor renderers resorting to the "SW"
rendering paths (as it can be seen with tablet support) to reuse the
same overlay, thus leading to flickering when a different
MetaCursorRenderer takes over the overlay.

Fix this by allowing per-cursor-renderer overlays, their lifetime
is attached to the cursor renderer, so is expected to be tear down
if the relevant device (eg. tablet) disappears.
2016-05-03 18:17:01 +02:00
Ray Strode
9f17c05a15 wayland: manually activate/deactivate stage when taking/dropping grab
clutter currently never emits activated or deactivated signals on
the stage object when using the EGL backend. Since the stage never
gets activated, accessibility tools, like orca, don't work.

This commit makes mutter take on the responsibility, by tracking
when the stage gains/loses focus, and then synthesizing stage
CLUTTER_STAGE_STATE_ACTIVATED state events.

A limitation of this approach is that clutter's own notion of
the stage activeness won't reflect mutter's notion of the
stage activeness.  This isn't a problem, in practice, and can
be addressed in the medium-term after making changes to
clutter.

https://bugzilla.gnome.org/show_bug.cgi?id=746670
2015-03-28 11:20:48 -04:00
Jasper St. Pierre
30953cf2d7 stage: Make the API take a CoglTexture
MetaCursorReference doesn't really need to be part of the API.
2014-08-21 15:04:58 -04:00
Jasper St. Pierre
467465c99c backend: Create the stage in the backend, rather than the compositor
This allows creating the stage much earlier than it otherwise would have
been. Our initialization sequence has always been a bit haphazard, with
first the MetaBackend created, then the MetaDisplay, and inside of that,
the MetaScreen and MetaCompositor.

Refactor this out so that the MetaBackend creates the Clutter
stage. Besides the clarity of early initialization, we now have much
easier access to the stage, allowing us to use it for things such as
key focus and beyond.
2014-08-13 20:08:46 -04:00