Re: PNG pictures have gamma correction twice applied

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

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

> entirely bypassed the whole folderol, and I would guess that for the
> rest 10% of users with 8bit per pixel devices, some low quality
> fallback (such as getting 64 fixed colors for 8bit display devices)
> would still be appreciated more than the current slow behavior of
> images.

The reason for the "closest color" code is to deal with the situation
where the aren't enough color slots available.  There might very well
not be 64 slots available.
I think this part of the code is OK, especially since I believe it is only
triggered in the very rare cases where it is needed.

But I agree that the lookup&gamma&caching is a bit strangely done and
is probably not ideal for displays with more than 256 colors.  I believe
the code for lookup has a comment that says essentially the same thing.

But I also remember that some of that code was done to try and reduce the
amount of X traffic (there were many calls to XAllocColor or XLookupColor
or something like that).
I think the caching could be improved (to reduce X traffic), tho.
And bypassing this code for PNG would be a good idea since libpng should
do a good enough (better) job already.


	Stefan