Around 15 o'clock on Nov 6, Olivier Chapuis wrote: > First why you choose to use 13 grey levels and not 16 grey levels?
So that 25%, 50% and 75% were all available. 13 gray levels give: 0.00% 8.33% 16.67% 25.00% 33.33% 41.67% 50.00% 58.33% 66.67% 75.00% 83.33% 91.67% 100.00% 16 gray levels gives: 0.00% 6.67% 13.33% 20.00% 26.67% 33.33% 40.00% 46.67% 53.33% 60.00% 66.67% 73.33% 80.00% 86.67% 93.33% 100.00% > Moreover, with 16 grey levels every thing is contained in the 16x16x16 cc. > > Moreover, 16 seems a better number than 13. 16 = 2^4 (may leads to > various simplification if dithering is implemented one day). These may well both be true, and we can re-evaluate which colors to use in the future if such things become relevant. > 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. Render provides for accelerated and network-efficient client-side text. Even if that text is strictly monochrome, it's still quite useful. Doing the emulation on the client-side will make networked applications significantly slower. > 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] Oh yeah, I'll go dig that up and apply it. Thanks a bunch. > 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? The colormap allocator isn't required to allocate colors in any particular order; the logic in that function is designed to handle the case where colors are allocated in some random order. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
