[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PNG pictures have gamma correction twice applied
From: |
Stefan Monnier |
Subject: |
Re: PNG pictures have gamma correction twice applied |
Date: |
Mon, 11 Nov 2002 12:43:50 -0500 |
> "Stefan Monnier" <monnier+gnu/address@hidden> 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"