Around 12 o'clock on Sep 21, Dr Andrew C Aitchison wrote:
> Although 8+24 overlay hardware support is very limited, PC hardware support > for DirectColor isn't uncommon. I take it you intend to emulate PsuedoColor > when DirectColor is available ? (Color-map flashing can be annoying, so I > wouldn't object to a server flag which had to be set to enable PsuedoColor > emulation.) Visual emulation is a requirement for RandR depth switching, but not vice-versa. RandR extends visual emulation by allowing the selection of which visuals should be accelerated, essentially the hardware is reprogrammed on the fly to select the desired acceleration mode and applications using other visuals get emulated. We've got samples of emulating PseudoColor visuals on TrueColor hardware and it's easy to see how you would emulate PseudoColor on DirectColor hardware. We don't have an example of emulating 24-bit TrueColor on an 8-bit pseudo color visual, but with Render, at least the appearance is well defined. The part that's hard is in switching which depth is accelerated and migrating windows between the real frame buffer and off-screen virtual frame buffers. The current X server architecture makes that problematic as there are many datastructures which embed knowledge of screen characteristics. So, we can move forward with visual emulation to provide PseudoColor visuals on True (or Direct) color screens. What Jim suggests is that we (at least temporarily) give up on the idea of switching the hardware around to match the currently active application. > "Rotate and Resize" doesn't imply "Redepth", so I can't really object, > but my interest in RandR has always been in the possibility of running > legacy 8 bit apps on a 24 bit screen. RandR doesn't have any (direct) impact on that. Just providing an 8-bit visual to provide PseudoColor for old apps is easy (if a bit slow). The trick is reprogramming the hardware and fixing up all of the server internal datastructures. Another important point -- legacy apps often assume that the 8-bit visual is the default. RandR doesn't address this issue at all; the default visual is not effectively switchable so RandR leaves the default visual alone making legacy apps suffer if it is not what they expect. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
