derek@shorty.cs.wisc.edu (Derek Zahn) (02/16/90)
Pardon me if this has appeared before. I have a rather large application (30,000 lines or so of C) that does a lot of SIMPLE_REFRESH window opening, closing, and movement. This program's users interact with it constantly for 8-12 hours per day, and it is expensive to restart. I have noticed that after running this program for a while, it gets SO slow to move a window that overall productivity dips significantly. The problem seems to be the list of rectangles that is used to figure out what is obscured and what is visible. The list associated with the bottommost window (a BACKDROP window, but that doesn't seem to matter) grows to a tremendous size when windows are moved around, and makes window movement very painful. Examination of this list revealed just what I'd have expected the underlying algorithm to produce, except that the rectangles are never coalesced into the largest and fewest possible. This appears to happen most often for the bottommost window. It seems to happen with SMART_REFRESH windows too. I am working on a 2500 running 1.3, though the problem appears on 2000s as well. I use Manx C, 3.6. Has anybody else noticed this problem? Is there some documented or undocumented function to coalesce the rectangles? I would do it myself (kludge) but the data structures involved are not well documented and I am afraid of breaking things even more. Another problem I am having is that if the screen of my application is LACE and I am using SIMPLE_REFRESH windows, occasionally the system software involved in moving a window will spray junk into other CHIP ram areas, including gadget image data and screen memory, BEFORE my program receives a REFRESH message. It's almost like the display code is starting to redraw the screen before the Layers code is finished figuring out where such drawing should be done. If anybody recognizes and/or can help (or sympathize) with these problems, please respond. Thank you for your time. derek
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/17/90)
In article <9748@spool.cs.wisc.edu> (Derek Zahn) writes: >The problem seems to be the list of rectangles that is used to figure out >what is obscured and what is visible. The list associated with the bottommost >window (a BACKDROP window, but that doesn't seem to matter) grows to a >tremendous size when windows are moved around, and makes window movement >very painful. You've hit it on the nose, the DeDicer as it's called doesn't dedice on window movement, only on "Window to front/to back" movement. To coalesce those puppies you need to bring a window to the front that covers everything and then throw it back to the back again. This is something that is supposed to be better in 1.4 (isn't everything :-)). I may not have the mechanics of the problem down exactly but that is the general area of the bug and it's been discussed on BIX a couple of times at least. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"