Around 12 o'clock on Sep 15, Mark Vojkovich wrote:
> Can render allocate the colors as needed and use whatever it
> gets? This would be more consistent with traditional PsuedoColor
> behavior. That is, first come first serve and if you don't like that
> use a private map.
Hmm. Not with the current protocol. Nor do I think it possible in
general.
As you know, pixels don't have RGB values in the core protocol. Render
imposes RGB values through PictFormats. For indexed PictFormats, it
provides for a static pixel<->RGB mapping.
For each indexed visual (i.e. those other than Direct/True), Render creates
an indexed PictFormat and initializes the static mapping by allocating
colors from an appropriate colormap. For the default visual, it uses the
default colormap. For non-default visuals, it creates a private colormap
that can be shared among all windows using that visual.
As any RGB value can be generated as a result of an image composition
operation, Render needs to be able to select an appropriate pixel value
with the assurance that it will be available. Attempting to do this
dynamically would require windows to switch colormaps on the fly -- if
Render was unable to allocate the desired color, it would have little
choice but to force the window to use a different colormap.
There isn't any provision to update the mapping dynamically; the data
are provided to applications without any asychronous notification of
change.
Given the ever-shrinking number of pseudo-color displays, I felt it was
more important that applications developed on TrueColor hardware work
without error on PseudoColor than that the PseudoColor hardware be used to
its best advantage. We've learned the hard way that developers make
incautious assumptions about how X visuals work; many PseudoColor
applications still fail on TrueColor displays. I was attempting to avoid
the reverse problem when designing this new extension.
The extension could be changed to allocate the color cube when the first
application requested information about it's contents; that would make
environments not using the Render extension work just like they did
before. However, I think that's a band-aid solution; users would have to
avoid most modern applications (all of KDE and Gnome) to make this work.
I see two easy solutions for this problem:
1) Have Render use fewer colors from the default colormap
2) Have XFree86 promote StaticColor as the usual default visual
The second would eliminate flashing for the vast bulk of applications while
causing strange application failures where assumptions about the default
visual class were made. The first would provide for Render applications
to run at reduced color fidelity, that may be acceptable for people
continuing to use older hardware incapable of running deeper than 8 bits.
[EMAIL PROTECTED] XFree86 Core Team SuSE, Inc.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
