Web lists-archives.com

Re: RFC: GtkPreview library

Cosimo Cecchi <cosimoc@xxxxxxxxx> writes:

> On Tue, Jan 20, 2015 at 10:24 AM, Carlos Garcia Campos <carlosgc@xxxxxxxxx>
> wrote:
>> One important thing is that preview providers should be out of process,
>> since unfortunately it's very easy to make things crash with buggy files
>> (which are very common). That could be done by every provider, but if we
>> force that at a higher level it would be much better. That would also
>> ensure that preview providers don't block the UI main thread, assuming
>> the communication with the provider processes will be always
>> asynchronous unconditionally.
> I ultimately agree, and I wrote a paragraph to that effect in my proposal...
> It's tricky to enforce this in the library, because it effectively means
> inventing a way for a process to draw into another process that doesn't
> look like libbonobo, and I didn't really want to go that path...

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.

> Cosimo

Carlos Garcia Campos
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

Attachment: signature.asc
Description: PGP signature

gtk-devel-list mailing list