Re: Question on gdk-pixbuf

[Lauris Kaplinski <lauris kaplinski com>]

On Mon, 26 Jun 2000, Nathan Hurst wrote:

> On Sun, 25 Jun 2000, Havoc Pennington wrote:
> 
> > Nathan Hurst <njh@hawthorn.csse.monash.edu.au> writes: 
> > 
> > That's not what I'm asking: "grayscale" typically doesn't mean RGB at all.
> 
> It didn't last time I looked.  It should!  Is there anyone on this list
> that wants a little project?
> 
> I would guess that useful operations would be:
> 
> copy from grey to grey
> copy from grey to colour(with mapping?)
> copy from colour to grey(Luminance?)
> paint flat colour in rgb, using grey as alpha channel
> copy rgb to rgb using grey as alpha channel
> 
> Some combinations of scale, etc.

This states one more time gdk-pixbuf-s need of coherent colorspace API.
I vote for adding colorspace enums, similar to OpenGL ones:
R8G8B8A8
R5G6B5
R16G16B16
C8M8Y8K8
etc.
Until there is no quality code, even silly converters would do. Plus
people actually needing something (say 16bit color) would then eagerly
write gdk-pixbuf routines, instead of private ones.

> Incidently, I am wondering whether it would be better to have a single
> parameterised function for doing pixbuf -> pixbuf transfer operations,
> detecting scaling, change of depth etc. automagically.  It might be a
> little slower than a direct call, but would be much easier to document and
> grok.  It might also be faster, if it can detect tricks efficiently(such
> as noting that a requested scale operation is actually 1:1).

Exactly :)

> I personally would like some form of clipping, either to svp, or some
> other efficient shape code.  If I get time I'll write this myself.

AFAIK libart new rendering has all that is needed to do pixbuf,SVP ->
pixbuf clipping. These should probably kept out from gdk-pixbuf own API,
as there are limitless combinations and these would do gdk-pixbuf much
fatter than it deserves.

> > Implementing gnome-font this way would be pretty stupid. The above is
> > just a simple way to do this using existing gdk-pixbuf features.
> 
> Yep.  But it would be better to implement gnome-font using the same tools
> as gdk_pixbuf so that optimisations in one lead to optimisations in the
> other.

I am not sure. Gdk-pixbuf will probably be most agressively optimized for
"normal" image sizes, i.e. something from 32-512 pixels (there is gnome
icon scaling to 20 pix. still). Font implementation usually needs most
optimization for ranges of 8-24 pixels. Glyphs larger than 32-64 pixels
are better rendered directly from outlines (cache of 1000 32*32 glyphs is
1 megabyte * bpp)

My 0.02

Lauris