anton@postgres.uucp (Jeff Anton) (12/04/88)
I'm writing a program that spends a lot of time computing each pixel of a window. What I would like to do is to have my program be informed when its window becomes obscured in a certain region so I don't have to waste computrons on unexposed window regions. The best I can figure out is to examine all the windows on the display to determine what I should draw on my one window. A lot of work that an application should not have to do in my opinion. With backing store I might as well go ahead and draw everything, but I would really perfer to present images to the user as soon as possible. The visibility events are of little use to me. Jeff Anton
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/05/88)
What I would like to do is to have my program be informed
when its window becomes obscured in a certain region so I don't have
to waste computrons on unexposed window regions.
There is no protocol support for this, sorry.jrg@Apple.COM (John R. Galloway) (12/06/88)
In article <7978@pasteur.Berkeley.EDU> anton@postgres.UUCP (Jeff Anton) writes: > What I would like to do is to have my program be informed >when its window becomes obscured in a certain region so I don't have >to waste computrons on unexposed window regions. > Jeff Anton Instead of initializing to computing for all pixels and getting events for regions not to work on, just do the reverse: assume there is nothing to do, and as you get expose events add the region specified in the event to the list of stuff to work on (compressing rectangles, and avoiding duplicates etc.). apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!
jrg@Apple.COM (John R. Galloway) (12/06/88)
In article <21703@apple.Apple.COM> jrg@Apple.COM (John R. Galloway) writes: >In article <7978@pasteur.Berkeley.EDU> anton@postgres.UUCP (Jeff Anton) writes: >> What I would like to do is to have my program be informed >>when its window becomes obscured in a certain region so I don't have >>to waste computrons on unexposed window regions. >> Jeff Anton > >Instead of initializing to computing for all pixels and getting events >for regions not to work on, just do the reverse: assume there is nothing Obviously my brain was not turned on here, you need both types of events to do what Jeff wants. Sorry, the system would not let me cancel it (yes you too can be embarassed nation wide :-). apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!
swick@ATHENA.MIT.EDU (Ralph R. Swick) (12/09/88)
> I'm writing a program that spends a lot of time computing each pixel > of a window. What I would like to do is to have my program be informed > when its window becomes obscured in a certain region so I don't have > to waste computrons on unexposed window regions. As rws pointed out, there is no direct (i.e. general) support in the protocol for this, but some applications may be amenable to the following hack: to determine the (instantaneous) visible region(s) of a window, or of a rectangular sub-region, while simultaneously destroying the contents, map a subwindow across the area of interest, then unmap it and process the resulting Exposures.
peterson@SW.MCC.COM (James Peterson) (12/09/88)
> I'm writing a program that spends a lot of time computing each pixel > of a window. What I would like to do is to have my program be informed > when its window becomes obscured in a certain region so I don't have > to waste computrons on unexposed window regions. What you would like, apparently, is a "VisibilityNotify" event. The main problem with the VisibilityNotify event as given is that it affects only the entire window, and you can't get events with a finer granularity. But suppose that you partitioned your window into smaller windows: for example, you could cut both width and height in half and you would have four windows: ------------------------ ------------------------ | | | | | | | | | | | | | (0,0) | (0,1) | | | | | | | | | | | | | ------------------------ | | | | | | | | | | | | | (1,0) | (1,1) | | | | | | | | | | | ------------------------ ------------------------ Now each of the smaller windows can get a VisibilityNotify event telling you if it is obsured or not. This allows you to avoid drawing in any subwindow which is FullyObscured. If you were to continue this process, you can clearly get FullyObscured or not FullyObscured events for as fine a granularity as you want (or can afford). In theory, for an nxm window, you could create n*m subwindows to cover it and give you bit by bit visibility. [Obviously, you could tailor your partition of the basic window to meet your application. For example, if you were displaying text, you could partition the window into rows, each row the height of a line of text. Then you would know if a given row was fully obscured or not.] How do we partition a window for this purpose? The easiest way would be to overlay the window with transparent subwindows. Transparent subwindows for X11 were dropped in favor of InputOnly windows and VisibilityNotify does not work for InputOnly windows. So I think what you would have to do would be to partition your window into multiple windows, each with a zero-width border and a background of NONE, to cover the basic window. This may cost more than it is worth. What is the cost? Well, one is that your program may become substantially more complex, since you will now be dealing with an array of windows, rather than a simple window. I'm not sure, for example, how you would draw a line from one arbitrary point to another arbitrary point, if you had to do it in the covering subwindows. Also, depending upon the granularity you choose, the number of events that must be handled could be very high. For example, if you did it bit by bit, a 100x500 window would be covered with 50,000 subwindows each with VisibilityNotify selected, and covering it with another window would generate 50,000 events; uncovering it would generate another 50,000 events.