Hi, 2010/9/2 Krzysztof Kosiński <tweenk...@gmail.com>: > 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 region copy is needed for incremental pixbuf load in GdkPixbufLoader, I think. If it isn't then I agree the function isn't super useful. The way I would see things working is that most of the image loader backends could continue to generate pixbuf's classic format, but if you'd asked for cairo format, the loader would create a second pixbuf in the cairo format and then copy over the areas as they load, exposing only the second cairo-formatted pixbuf to the application. (Assuming the app has requested cairo format.) I initially had a function that did a "destructive" convert of a pixbuf, which was in-place if possible. A trick is that all props on pixbuf are currently immutable (CONSTRUCT_ONLY). We could change that, of course. But it's sort of a messy change for only an optimization, and it's not like setting n_channels post-construct is allowed, so removing CONSTRUCT_ONLY is kind of wrong. Also, for the incremental load, you would end up with a pixbuf that was partly in one format and partly in another format. That would be... weird. Though it might work. Making the PNG and JPEG loaders load without a convert, and adding cairo's formats to the pixdata inline stuff, might be good enough to avoid conversion in practice in almost all real applications. With copying convert as a rare fallback which could just be slightly inefficient instead of in-place. i.e. TIFF support can have some extra overhead and we'll survive it. i.e. the idea is that in-place conversion is sort of thorny and the optimization really isn't important as long as we avoid conversion in the three or so common cases. And avoiding conversion entirely does save CPU, while in-place only saves memory but still uses CPU. > 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. The only reason to modify the loaders would be efficiency, just to avoid a convert. My thought was to first implement loading with a convert fallback, but then as an optimization, loaders could support directly loading to the proper format. Whether we optimize with an inplace convert or with loaders knowing about the destination format, a copying convert seems like a simple place to start, so that's why the initial API here is copying. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list