greg@harvard.UUCP (Greg) (05/08/86)
I have found what seems to be a QuickDraw bug. If you have a funny-shaped window, like an apple, and you drag the window upwards, then it redraws the window very quickly. If, however, you drag the window downwards, it redraws the window very slowly; the delay is unacceptable. Apparently, a region is stored as a linked-list of horizontal scan lines. When you move a window on the screen, the Window Manager calls CopyBits to copy the window contents. Normally CopyBits runs from top to bottom, using the scanlines of the region in order. However, if you are copying from a grafport, like the screen, to itself, then CopyBits may have to copy the image from bottom to top so that it won't lose information during the transfer. This is potentially a problem for regions. CopyBits must traverse the linked list of scan lines in reverse to handle this special case. And here is where the ROM goes bad. Instead of making an array of links and accessing it in reverse order, or instead of putting all the links on the stack and popping them in reverse order, CopyBits simply goes through the linked list again and again for each scan line. Its algorithm takes quadratic time instead of linear, and QuickDraw turns to SlowDraw. But, you might object, what about the extra space that the array would take up? Well, if you are really concerned about space, you can check to see if there is enough distance between the stack and the heap to store the array, and if there isn't, you can use the brain-damaged algorithm. But this issue will come up very rarely; the extra array is necessarily smaller than the region that CopyBits is dealing with, so there is usually enough room. Not that being low on space should stop QuickDraw. My roommate (Jimmie Matthews) and I found a totally different QD bug which wastes *both* time and space. When you fill a polygon on the screen, it converts the polygon to a temporary region and then fills the region. It will convert the *entire* polygon to a region, even if most of it is off the screen. So if only ten percent of your polygon is actually on the screen (or equivalently, in the GrafPort), Quickdraw uses ten times more space and time than it needs. If you don't have enough space, that's just too bad; you usually get a system crash. Some of our polygons were plenty big enough to cause a crash; I ended up writing my own clipping routines (Ugh!). I am currently working on a magnifying glass desk accessory, with a magni- fying-glass-shaped window, and I find this bug extremely annoying. Any comments from Apple? -- gregregreg
greg@harvard.UUCP (Greg) (05/10/86)
In article <932@harvard.UUCP> greg@harvard.UUCP (Greg) writes: >Apparently, a region is stored as a linked-list of horizontal scan lines. When >you move a window on the screen, the Window Manager calls CopyBits to copy the >window contents. Normally CopyBits runs from top to bottom, using the >scanlines of the region in order. However, if you are copying from a grafport, >like the screen, to itself, then CopyBits may have to copy the image from >bottom to top so that it won't lose information during the transfer. Someone at General Computer who actually poked around in the ROM has pointed out to me that a region is not stored as a linked list of horizontal scan lines, but simply as a consecutive list of horizontal scan lines. However, since the scan lines have variable length, the problem persists. The rest of my article is correct. -- gregregreg