On Fri, 9 Nov 2001, Mark Vojkovich wrote:
> On Fri, 9 Nov 2001, Jeremy wrote:
> Contrary to some opinion on this list, overlays are not intended
> to make legacy PseudoColor apps work. Overlays in the X-window
> system are for layers of windows that don't clip other windows.
I'll accept that. While I knew that was how the various overlays used by Xv
and friends worked, I perceived the 8+24 Pseudo/True differently for whatever
reason (I think largely because compatability with old apps was the best
reason for its existence I could posit).
Also, I suppose I was just concerned with the fact that they had different
visuals and I didn't expect two windows on any two arbitrary visuals not to
clip each other. Do they? Is there any way to tell if a non-default visual
is an overlay (other than assuming anything with a different depth is)?
> > Here's the progression: Initially, the TrueColor window is solid black.
> > Whenever the PseudoColor window fills in its topmost colormap entry, I
> > convert its color to its corresponding 24 bit TrueColor value and pass it to
> > XSetWindowBackground(). Unfortunately, all of the 'transparent' PsuedoColor
> > pixels remain (or the old background color of the TrueColor window) until I
> > drag the whole thing (TrueColor window and enclosed PseudoColor window) off
> > the screen and back on, or obscure it, or something else. As soon as I
> > obscure and re-expose it, the new background shows through and the
> > PseudoColor window looks like all 256 colors are correct.
>
> XSetWindowBackground() doesn't redraw the background it only
> sets the new background value that will be used the next time it gets
> exposed, which by design, is hardly ever because that's the whole
> point of overlays. If you want to clear this to the background
> you use XClearArea() or XClearWindow().
Yep. Hence below...
> > I assumed that meant I had to call XClearWindow() on the TrueColor window
> > after changing its background, but that didn't help. Maybe XClearWindow()
> > does think the TrueColor window is obscured, even though the server clearly
> > doesn't. So, I tried calling XClearWindow() on both the TrueColor window and
> > the PsuedoColor window and then redrawing the whole PseudoColor image. No
> > improvement, just a whole lot of flicker.
>
> Calling XClearWindow() on the TrueColor window should work just fine.
> It's not clipped by covering PseudoColor windows and I'm not aware
> aware of any bugs in that code. Sounds like you're saying it doesn't
> work anymore. If that's the case, I'll have to take a look at the
> code again.
To the best of my knowledge, I did precisely that. I created both windows up
front, with the PseudoColor window a child of the TrueColor window. I then
called
XStoreColors() on the PseudoColor window
XSetWindowBackground() on the TrueColor window
XClearWindow() on the TrueColor window
XInstallColormap() of the new Colormap
At this point, the new colormap does take effect on the PseudoColor window,
but the transparent PseudoColor pixels still show the previous background of
the TrueColor window. However, dragging other toplevel windows over and then
away again redraws with the new TrueColor background color.
For fun I tried XClearWindow() on the PseudoColor window too, but that didn't
help, and then I gave up and wrote the prior piece of mail.
-Jeremy.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
