On Mon, Nov 04, 2002 at 10:05:16PM -0800, Keith Packard wrote: > I've implemented a simple configurable mode to control how many colors the > Render extension allocates on dynamic indexed visuals (pseudo/gray). >
There are few things that I do not understand. First why you choose to use 13 grey levels and not 16 grey levels? This does not make a big difference on the number of colors. The 4 grey of the 4x4x4 cc are also grey of the 16 regular grey. Moreover, with 16 grey levels every thing is contained in the 16x16x16 cc. So, the 32x32x32 cc (respectively, the 32768 ramp) can be replaced by a 16x16x16 cc (respectively, a 4096 ramp) for approximation. No? I miss something? Moreover, 16 seems a better number than 13. 16 = 2^4 (may leads to various simplification if dithering is implemented one day). ((From a theoretical point of view with a XxXxX cc it is a good idea to add a X^2 ramp. The grey of the cc are in the ramp, the number of colors is X(X^2+X-1) and the zeros of this equation are well known magic numbers :o)) Secondly, I do not understand the "mono"/"grey" argument to -render. I understand "mono"/"grey" when it is the default. However, as an option with a 256 PseudoColor Cmap I am totally lost ... as a developer. I used XRender in my programs for displaying text (Xft) and icons. We have functions which can perform XRender emulation for X server/driver without render support. If I detect that Render is present and use just black and white I will surely do not use it. So it seems that in this case "mono" == "-no-render"? IMHO, a -no-render/NoRender option (for any visual) is more adapted (and as a "ServerFlags" the implementation is trivial I think). Why I like it? Because, I can test my programs for an X server without Render by just using this option (no need to recompile). You say in an e-mail something like "Why NoRender? There is no NoShape!". But I will be happy with a NoShape option for the same reason. Ok this is just my 2 cents I do not want to polemic. Finally, I send a patch to this mailing list for an implementation of QueryPictIndexValues (Render proto). Are you interested? I can recheck it, make the patch against the current cvs I send it to [EMAIL PROTECTED] About this, I've one trouble. It is the first / last Pixel logic in render/miindex.c. For me in any case at the end first = 0 and last = "nbr of colors" - 1. No? Why this troubling logic? Thanks, Olivier _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
