chandran@ASC.SLB.COM (03/23/90)
In response to the question: > | How do I create the "invisible (shadow/outline) windows" that > |"twm" uses when a user moves his window (so that the user knows where > |the destination is going to be)? jimf%saber@harvard.edu says [Thanks, Jim, Tom, Gary ...] > The simplest way is something like: where he outlines(!) a method in which one draws [a rectangle] into the root window (and then "undraws" it when the pointer moves). This is all fine, but it seems to beg the question and exposes (!) what seems to me to be a technical limitation of X. The question was how to make transparent windows, though I admittedly lead people to the wrong track by assuming that "twm" has that capability. In particular, consider the situation where we have to produce complicated graphics into a window. The desired effect is to have whatever is behind the window show through (no matter where the window is currently positioned). The proposed solutions requires one to Translate to the root window, draw the graphics, and undraw them when the window moves!! Wait a minute. One of the major wins of windows was that this organisation is automatically done for you by the window system. ("Why not draw everything into the root window?") You mean the client has to do all the dirty work? I (admittedly, a neophyte) don't understand what the technical difficulties are in providing this capability. If I can make the "background" appear when I change a window's stacking order, can't I pretend that is what is happening when I create a transparent window? What is the main purpose of "window_background_pixmap" to be "None"? Regards,
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (03/23/90)
> In particular, consider the situation where we have to produce > complicated graphics into a window. The desired effect is to have > whatever is behind the window show through (no matter where the window > is currently positioned). You could always use the SHAPE Extension, and shape your window to the graphics. This gives almost exactly the same effect as a transparent window. Of course you are going to generate a bzillion exposure events, and really beat on your server and the other clients on the display. Transparent windows will have the same problem, however. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/23/90)
"Transparent" windows are a tricky subject, there are many possible
interpretations of this term. (The core X protocol provides no
support for any of them, I suspect.) NeWS has a special kind of
canvas (overlay) that provides one kind of transparent window, but
I think that you will find the semantics very contrained.
In particular, consider the situation where we have to produce
complicated graphics into a window. The desired effect is to have
whatever is behind the window show through (no matter where the window
is currently positioned).
You have switched between these two sentences. There is a difference
between doing "overlay" graphics across multiple windows (or requiring
that it be done in a separate window) and doing overlay graphics in
the same window as the underlying graphics. Overlay graphics can be
done within a single window, given certain assumptions. You can examine
the color chapters of the some of the X books for examples (e.g. O'Reilly
volume 1 chapter 7).
There is display hardware that has a notion of "overlay" planes, and
of "blending" multiple images on the screen. Several companies have
private extensions which integrate this hardware into their X server.
There is work going on in the X Consortium to try and standardize such
an extension, although it is slow going so far (it is a difficult topic).
What is the main purpose of "window_background_pixmap" to be "None"?
The main purpose is a minor performance improvement. If the application
is simply going to cover the entire window with graphics (i.e. there is
no reasonable "background" that can be supplied), then why bother forcing
the server to spend time painting the background? That is the primary
reason, although the mechanism can be used for other tricks.jimf%saber@HARVARD.HARVARD.EDU (03/23/90)
|In particular, consider the situation where we have to produce |complicated graphics into a window. The desired effect is to have |whatever is behind the window show through (no matter where the window |is currently positioned). The proposed solutions requires one to | | Translate to the root window, draw the graphics, and undraw |them when the window moves!! Won't work if there's a repaint from a window below yours; X will clip around your "transparent" window and no update will happen, or the window will draw through your window -- destroying it -- and you'll not be told to update it. |I (admittedly, a neophyte) don't understand what the technical |difficulties are in providing this capability. There are no technical difficulties, only synchronization problems when you're using a non-retained windowing system. If X had been designed as a retained system this would be a snap, but it would require a lot more memory to run. Currently the shape extension can do what you want but it slows down a LOT if you use a complex shape or change things often. The memory problem can be partially alleviated by creating an object-oriented environment where your objects are some type of higher complexity than a pixel (eg rectangle, ellipse, whatever). You can rebuild the pixel image by redrawing the objects and all you've lost is some CPU time. This is what you end up doing with X anyway so you really don't loose anything and you simplify your applications dramatically (they don't have to remember how to redraw everything because they never see a repaint [expose] event). Once you have a retained layer, creating transparent windows is as simple as drawing from the bottom up and clipping around things as necessary. The code to do so with good efficiency is remarkably simple. I implemented a library layer which created a retained object-oriented environment under X11R2 about a year and a half ago, with excellent success in both memory requirements and performance (and portability -- a co-worker [hi Joe] ported it to SGI GL in about four hours). Hopefully someday I'll have the time to reimplement a public-domain version.... jim frost saber software jimf@saber.com