The case for a "SceneGraph"

[Michał Sawicz]

W dniu 19.07.2013 01:58, Gerry Boland pisze:
> What shell will need is, for every surface, the following properties:
> - x, y, z, width, height
> - opacity, visible
> - scale
> - ability to set more complex transformations/shaders, so can desaturate
> surface colours, do more advanced animations, blurs etc.
> 
> Shell will implement window management through QML. I would like to have
> as much flexibility with surfaces as the Qt Scenegraph gives me with
> Items [1] [2].

FWIW every time I think of a list of things we'll need to communicate to
the compositor, it feels like we're doing something wrong. We'll
basically have two SceneGraphs (one of the shell, one Mir-internal) and
will have to keep them in sync.

This, I feel, might make it really difficult to achieve some UX that
we're wanting for. It also makes it difficult to think security when
letting others render to the shell (think video/map in dash, custom
infographics, even OSK).

I'm sure it was discussed before, but can you guys please give me a
summary why it's not possible to just keep the shell's scenegraph (in
our case the Qt/QML one) in play? Or if there maybe is another way for
shell's scenegraph to another process's surface for "internal" composition?

Cheers,
-- 
Michał (Saviq) Sawicz <michal.sawicz at canonical.com>
Canonical Services Ltd.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20130719/a418c9ec/attachment-0001.pgp>