[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree-xpert
Subject:    Re: [Xpert]Colormap Allocation problems under Linux 7.3
From:       Olivier Chapuis <olivier.chapuis () free ! fr>
Date:       2002-10-23 20:27:58
[Download RAW message or body]

On Wed, Oct 23, 2002 at 08:31:37AM -0700, Keith Packard wrote:
> Around 9 o'clock on Oct 23, Olivier Chapuis wrote:
> 
> > An application should query if the xserver has render support and if not
> > take appropriate decisions. No? E.g., in FVWM we have a function which
> > simulate XRenderComposite and a font spec can have two fonts one for Xft
> > and an other one for core text rendering.
> 
> Client-side text is a powerful mechanism which is not easily replaced with
> core fonts.  Xft uses the core protocol GetImage/PutImage when Render is
> not available, but performance suffers greatly.  Applications like 
> OpenOffice (and FrameMaker) are unable to provide reasonable text output 
> with the core font primitives.  Client-side text is useful independently 
> from anti-aliasing.
> 
> > In some case it is not the number of colors which counts but how the
> > apps share the colours.
> 
> Our working assumption is that 8-bit PseudoColor displays are useful only
> for legacy applications; those don't generally share well with others as 
> they need custom or writable color values.  Any significant number of 
> preallocated color cells generally cause these applications to fail.
> 

Agree with the working assumption. But, if we take as example the mail
which starts this thread, what it is needed is only 2 writable colours
and 16 normal one. So, I will add that we _may_ have only one such
"legacy application" which needs only a few colours.

> > Moreover, if you use standard dithering methods, dithering is really really
> > better in mode #5 and #6 than in the default mode.  So I think that
> 
> Render doesn't (currently) support dithering, and dithering to a random set
> of colors is rather expensive.  I like having both a color cube and a gray 
> ramp as I believe that provides more accurate anti-aliased text, I'm not 
> sure how dithering fits into this model.
>

I do not know too. I made various dithering experimentation with a
color cube + a ramp, but not yet found something which _never_ gives a
less good result than dither only in the cube.  Also I think as you
that a cc + a ramp is good. I do not think that all these gamma
corrected (maybe spherical) pallet and visual colour distance can
_really_ give improvement. My only success is a better color distance
than the euclidean distance when we have a "big" ramp compared to the
size of the color cube:
 
 |r1-r2| + |g1-g2| + |b1-b2| +
	f*(|r1-g1| + |g1-b1| + |b1-r1| - (|r2-g2| + |g2-b2| + |b2-r2|))

this distance forbid colours to become grey and grey to become coloured.
 
> > Yes, using StaticColor is more or less equivalent than mode #6 (but
> > with a bit different colours proportion (3/3/2) by default).
> 
> The new fb frame buffer code fits the largest color cube and fills the 
> remaining entries with a gray ramp, precisely as you've described for mode 
> #6.  PseudoColor with a completely allocated colormap is a poor substitute 
> -- with StaticColor, the server will automatically fit new color requests 
> into the existing color entries, while PseudoColor will fail the 
> allocation request.
> 
> > I think a "full" mode does not hurt and assure backward compatibility.
> > But, I do not care. I am more interested by mode #5.
> 
> Any PseudoColor mode which doesn't permit the bulk of legacy applications 
> to run without problems isn't interesting in this context; it may be that 
> the 'default' mode can allocate a few more colors than it does in current 
> CVS, but I don't think it should use a 5x5x5 cube
> 

256 - (5*5*5 + 32 or 16) + 2 = 101 / 117

I think that maybe the user which starts this thread will be happy
with this (until it uses a modern app which does not care about (or
can not be configured to detect) the 5x5x5+32 or 16 allocated cc+r) 

other solutions:

256 - (5*5*4 + 32 or 16) + 2 =  126 / 142
256 - (4*5*4 + 32 or 16) + 2 =  146 / 162

"a" default (for comparison):

256 - (4*4*4 + 16) + 4 =  180

If I was an X expert I will allows all the above mode, but I am
only a poor FVWM workers :o). So, if the principe of the patch
I post in this thread is accepted, I will finish it following
your suggestion ...

An other point, maybe XRender should has a function which
describes the colormap it uses (for depth <= 8 && PseudoColor).

Regards, Olivier
_______________________________________________
Xpert mailing list
Xpert@XFree86.Org
http://XFree86.Org/mailman/listinfo/xpert
[prev in list] [next in list] [prev in thread] [next in thread]