On Fri, 9 Nov 2001, Jeremy wrote: [...]
> The most annoying, however, has got to be dealing with the colormap on the > PseudoColor visual. XCreateColormap() is happy to claim to give me a 256 > entry colormap, but, I'm assuming because of how the overlay works, entry 255 > (the topmost) doesn't work. What's interesting is how it doesn't work... > > I'm guessing that the hardware uses the value 0xff in the high 8 bits to > signal that the bottom 24 bits (i.e. the TrueColor portion) should be > displayed. That means that I'd expect any pixel in my Window with a value of > 0xff to show whatever the last TrueColor pixel displayed at its current > position (in the host framebuffer) and, indeed, with a toplevel overlay > window, I do see any obscured TrueColor windows start to bleed through. > > However, if instead my PseudoColor window is a child of a TrueColor window, > then the 0xff pixels of the PseudoColor window display appear with whatever > pixel is in the corresponding pixel of the TrueColor window, even though the > TrueColor window is completely obscured by its child. That makes it seem > like the server considers 24 and 8 bit windows independently, at least for > clipping and obscuring calculations. 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. One of the features of overlays is a transparent pixel or pixels. This is advertised in the SERVER_OVERLAY_VISUALS root window property. Run Netscape, place an Xterm on top of it, place xcmap on top of that. Scroll Netscape and you will see through xcmap's transparent pixel that Netscape is not clipped by the obscuring windows since they all lie in different planes. There is an overview of this at http://www.hp.com/xwindow/sharedInfo/Whitepapers/Visuals/visuals.html#OVERLAY_PLANES We should technically only offer 255 colors instead of 256, but guess what? All the stupid legacy apps that create their own colormap and allocate 256 colors break. So instead we let you allocate 256 and let you change which pixel value is non-working with a config file option, so you can minimize the artifacts of having a non-working pixel. We actually do preallocate the color key on the default map, it's only the ones created after that which we don't because of the broken apps that expect to be able to allocate all 256 values in a private map that they create. The whole point of overlays is to minimize exposures on 3D windows. Popups and toolbars go into the overlay while the 3D apps go into the Image plane. You can also do neat transparency effects with overlay windows. The GLUT toolkit, for instance, puts all it's popups in the overlay when available. > > That's kind of cool, because it presents me an excellent way to fake that 256 > palette entry (the one that's stolen from the PseudoColor visual to key the > overlay)-- convert it to TrueColor and make it the background of the > enclosing TrueColor window. The catch is that no amount of contortion on my > part appears to be able to programattically redraw the TrueColor window when > its background changes. > > 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(). > > 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. Mark. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
