Web lists-archives.com

Re: RFC: GtkPreview library

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@xxxxxxxxx> 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


Attachment: signature.asc
Description: This is a digitally signed message part

gtk-devel-list mailing list