Hi, On Thu, Sep 2, 2010 at 5:07 PM, Matthias Clasen <matthias.cla...@gmail.com> wrote: > One thing I wonder about though: one of the big reasons to keep > GdkPixbuf around is the image loaders. But in this scheme, every > pixbuf thats loaded from a file would end up with an old-style > internal representation, right ? >
Loaders would have the option of using new_from_data() or new_from_cairo_surface(). We would probably say new_from_cairo_surface was preferred and port the interesting loaders to do that. I was thinking about the problem of wasting memory, writing to one internal representation and not changing the other, etc. How about this: we only keep one representation around. If you get_pixels we drop the surface, if you get_cairo_surface we drop the old-style pixels. We deprecate get_pixels() which is the only call that can force the old-style representation to be created. If you do use get_pixels(), what's going to happen is that you do your pixel editing, and on the next paint gdk_pixbuf_get_cairo_surface() will force conversion back to cairo representation. So the only "big fail" case is where you want to modify the pixbuf pixels on every frame, or with some frequency. Those cases would just have to be ported over to cairo_surface usage. But hang on: gdk_cairo_set_source_pixbuf() currently converts on *every paint*, *always*. So we have some evidence that this isn't even a huge deal. With the loaders, if they are unmodified then they create in old-style, but on first call to get_cairo_surface we drop the old style pixels. If they are updated to start from a surface, then the old-style is only created if someone uses deprecated get_pixels. I'm liking this approach. It's minimal code, and easy to make correct. The "hard part" is purging get_pixels usage, but that is a performance issue only, not a correctness one, and unlikely to be worse than gdk_cairo_set_source_pixbuf already is. Am I missing a big downside? Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
