On Wed, 24 Oct 2001, Dr Andrew C Aitchison wrote:
> On Wed, 24 Oct 2001, Mark Vojkovich wrote:
>
> > On Wed, 24 Oct 2001, Dr Andrew C Aitchison wrote:
> > > While I don't know of any plans, and I agree that the app is indeed the
> > > problem, I think the hack to implement PseudoColor on DirectColor should
> > > not be too hard - at depth 24 the two visuals are just different ways of
> > > interpreting the colormap.
> >
> > You have to do it with shadow buffers for every depth 8 window.
> > Whenever you change the palette you have to redraw (retranslate) the
> > 8 bit data. You won't pass the test suite if you can't read back
> > the 8 bit data you've just written. In theory you could have any
> > number of PseudoColor maps though.
>
> Can't you just put the 8 bits into each of the red, green and blue
> bytes in the DirectColor framebuffer ?
Oh. I guess so. That cuts out cheap hardware like Virge,
but works on most everything else.
> Then the hardware palette will think it is doing 3 8bit->8bit
> lookups, but logically it will be doing 1 8bit->24bit lookup.
>
> Having to read the data back makes it tempting to use
> depth=8, bits_per_pixel=32 pixmaps.
You'd need to add framebuffer support anyhow so you might as
well just use depth 8, 8 bpp pixmaps. It's more than a matter
of just modifying fg, bg and pm. PutImage has to work and
you need to hack the frambuffer for that.
>
> This will give you not only the fast colormap updates which
> apps which have a reason for pseudocolor need,
> but also the colormap flashing which dumb p.c. apps force on use.
> Generally an accurate implementation of pseudocolor.
Yes, I'm sure it will be quite nostalgic to see color flashing
on a 24 bit display :)
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
