Re: pixbuf<->cairo_surface_t conversion

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

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?


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:
> 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

Un saludo,
Alberto Ruiz

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]