On Sun, 2015-01-25 at 07:22 -0500, Cosimo Cecchi wrote:
On Sat, Jan 24, 2015 at 4:33 AM, Carlos Garcia Campos
<carlosgc gnome org> wrote:
I'm assuming the providers will render the contents into
surfaces that
the previewer will compose, not providers directly drawing
into the
previewer. We can share the bitmaps between processes without
using
anything like CORBA, simply using shared memory and sending
the file
descriptor with dbus. Note that providers might not be
asynchronous, or
thread safe.
I can see a few problems with this approach:
- data is not always a static bitmap. You can preview arbitrary
complex things like webpages, videos, presentations, etc. In the
future even possibly complex CAD drawings or whatnot, if a module gets
written for them.
- the problem with doing this generically is that there needs a system
that notifies what has been invalidated in order to redraw, something
that forwards input events, etc.
- ideally we don't want to copy every frame while doing that
Bastien's suggestion to use (wayland) sub-surfaces sounds like a much
better fit, as they're designed specifically to address some of these
problems. My understanding is that it requires writing a small wayland
compositor in the widget itself; not sure yet what'd be involved with
this. There's also a question about what to do on backends (like X11)
that don't really support such a thing. I guess we could use XEmbed on
X11, but I can see it turning messy pretty quickly.
That's why my proposal doesn't enforce this specific design; I'm
definitely open to think more about how a multi-process design looks
like, but I wouldn't want to block until that is figured out.
To me, the security and rendering architecture of this seems pretty core in the design, so I _would_ block on figuring it out. It doesn’t feel like the kind of thing which can easily be bolted on or fixed afterwards. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part