The case for a "SceneGraph"
Christopher James Halse Rogers
chris at cooperteam.net
Thu Jul 25 09:45:23 UTC 2013
On Thu, 2013-07-25 at 03:40 +0200, Michał Sawicz wrote:
> W dniu 25.07.2013 01:28, Robert Carr pisze:
> > I don't mean to raise FUD but it is unclear enough to me that I would
> > not know the first step if assigned it as a task (My first question
> > would be, does ms::Surface implement QQuickItem? If not, how do we avoid
> > two copies of the SurfaceStack). I also think that, ease of applying
> > graphical effects, is not really something holding us up at the moment,
> > or something likely to be a significant drain on development resources
> > any time soon.
>
> The biggest benefit that I would see from this is the ability to
> composite a surface on top of another, treating it as any other Item in QML.
>
> My usecase: being able to render $your_favourite_part_of_the_shell_ui
> out-of-process, while maintaining all of the transitions & animations
> designed for that part of the UI.
>
> Reason: stability, security, flexibility. This would mean, that, for
> example, the video player could be embedded in the dash video preview
> without the risk that it would bring down the shell if the video file
> was broken.
This is something that we have to support anyway; roughly all video
players work this way. You'd have an empty dummy Item and have the video
decoder fill that.
Of course, we don't have this implemented, nor do we have a concrete
plan to implement this. It might be implemented with EGLStreams, or by
sharing surface IDs across process, or somehow.
We do need to implement it, though, and it'll solve your
embed-out-of-process-thing use-case.
More information about the Mir-devel
mailing list