Re: pixbuf<->cairo_surface_t conversion
- From: Alberto Ruiz <aruiz gnome org>
- To: Andrew Cowie <andrew operationaldynamics com>
- Cc: gtk-devel-list gnome org
- Subject: Re: pixbuf<->cairo_surface_t conversion
- Date: Fri, 3 Sep 2010 09:29:17 +0100
Hello there,
at college, we used get_pixels for concurrency assignments where we
used Ada. (Histogram analysis, shape detection and whatnot)
The problem I see with removing this is that you actually need to make
a roundtrip from the GDK API to cairo_get_surface -> cairo_get_data
which would not be a very obvious step from the API user point of
view.
If we are trying to keep things cairo internally, can't we just leave
get_pixels as a wrapper around cairo's get_surface/get_data if that's
how people are going to have to use it anyway?
Cheers,
Alberto
2010/9/3 Andrew Cowie <andrew operationaldynamics com>:
> On Thu, 2010-09-02 at 19:24 -0400, Havoc Pennington wrote:
>> 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...
>
> Deprecate¹ implies removal at either GTK 3.0 or GTK 4.0, right?
>
> So I guess the question I have is "is there ever a legitimate usage to
> get the individual pixels".
>
> Our binding of this right now is:
> http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gdk/Pixbuf.html#getPixels()
>
> which is mostly used by us for testing; I couldn't begin to guess what
> other people have used it for; I do know one crew that actually did some
> image recognition work (feeding some other library from these byte[]).
>
> We can kiss gdk_pixbuf_get_pixels() goodbye, no problem, but I'm just
> curious what someone would replace it with... draw to a Cairo image
> surface, save that to a PNG and then load it and... oh wait. :)
>
> As usually happens across the language barrier, we had to copy the array
> anyway, so I'm not really fussed where we get it from. Or, are we
> advised to tell developers "no more access to an image's pixels"?
>
> {shrug}
>
> AfC
> Sydney
>
>
> ¹ "deprecate" of course means "don't use this it's been replaced" or
> just plain "don't use it" but in GTK during the long lifespan of 2.x
> we've also used it to mean "we'd rather you didn't use it but it's still
> ok"... because (until the last ~18 months) we were in
> ain't-never-ever-gonna-remove-functions mode.
>
> Now we're actually removing stuff! Who would have thunk it :)
>
> I think there's some inconsistency in our library as a result of this. A
> number of times over the last few months Javier has had his enthusiasm
> pushed back when he's seen "rather you didn't use this", not known "it's
> still ok", and thought it should be removed only to be told to leave it
> alone.
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
--
Un saludo,
Alberto Ruiz
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]