On Sun, 2015-01-25 at 07:22 -0500, Cosimo Cecchi wrote: > On Sat, Jan 24, 2015 at 4:33 AM, Carlos Garcia Campos > <carlo...@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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
