Re: pixbuf<->cairo_surface_t conversion
- From: Krzysztof Kosiński <tweenk pl gmail com>
- To: Havoc Pennington <hp pobox com>
- Cc: gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: pixbuf<->cairo_surface_t conversion
- Date: Thu, 2 Sep 2010 18:21:37 +0200
2010/9/2 Havoc Pennington <hp pobox com>:
> See bugs:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=395578
> https://bugzilla.gnome.org/show_bug.cgi?id=491507
>
> I'm attaching a patch which proposes some API to make GdkPixbuf
> support the cairo RGB24/ARGB32 formats.
> In this patch, there's no actual code to convert, it would come from
> gdk/gdkcairo.c, I didn't mess with it yet.
The functions are unnecessarily general. Only two functions are
needed: an in-place conversion of an entire pixbuf, and duplication
with conversion (to cover cases where the number of bytes per pixel is
different, or lossy conversion). There's no need to support copying
regions between pixbufs with conversion, because compositing is
Cairo's job.
> The idea would be to have a second patch, which would let you set up a
> pixbuf loader to load the new formats; the pixbuf loader would then
> convert on the fly for backends that didn't have support for the new
> formats, initially that'd be all of them. But we could give loaders a
> "format hint" later.
The conversion between non-premultiplied BE RGBA to premultiplied
native-endian ARGB is lossless in practice. E.g. even if you convert
back to non-premul, it doesn't matter in most cases, because to
display the image on the screen you'll have to convert back to premul
anyway. So instead of modifying all the loaders, we could just convert
to the new format after loading.
Regards, Krzysztof
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]