Re: PNG pictures have gamma correction twice applied

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > > Now x_alloc_nearest_color is defined in src/xterm.c.  It first calls
> > > gamma_correct on the function in question (which does the gamma
> > > correction with a very expensive floating point operation), then
> > > calls x_alloc_nearest_color_1, which does a costly operation of
> > > figuring out a closest color.
> > 
> > Have you checked whether this "costly operation" is actually done
> > in your case ?  It should only happen if the XAllocColor fails, which
> > should never be the case in a 16bpp (or more) display.
> 
> Correction: which should not be the case when there is no palette
> involved of any kind.  If there is, XAllocColor will allocate the
> next free color slot.  Since the Emacs display code never deallocates
> a color again, the color palette will run out of colors eventually.
> Whatever colors happen to be in the palette at that time, get used
> for the "closest" color.  If you have, for example, a color diagram
> as an image, the red top will allocate all the colors away, and blue,
> green and white will be all represented by shades of red.

IIUC, the problem is not with the closest-match thing per se, but with
the fact that Emacs doesn't deallocate colors.  And that for images,
it's probably better to pre-allocate a set of colors and stick
to them, since most images will otherwise overflow the 256-color palette.
Agreed.  The code you're looking at was really meant for text originally.

> For that reason it would be more prudent to allocate a fixed palette,
> even if it has just 4x4x4 colors, and use that.

For images, yes.  For text, I don't see the need: I hate it when an
application allocates 64colors of my small colormap only to use 10 of them;
and doesn't even get them right because it approximates
within the 64 it pre-defined rather than using the exact color.

> Just making use of whatever happens to be present in the current palette
> is an emergency measure.

For some users, it's the "normal case" (many apps gobble up most/all the
colormap).

> And asking for the current palette again for every new
> pixel is not going to be reducing the X traffic...

That's the part of the caching which could be improved.


	Stefan "who cares about 256-color displays and Emacs displaying text
		much more than about Emacs displaying images"