sorry for top posting.... I'm using my mobile phone...
yes it's true, there is such an optimization... Suggested by PeP... I
always wanted to remove that experiment because it caused menu redraw
problems... But then
I forgot about it :) funny....
Nah come on:) This sounds weird. I don't write bugs.
I don't remember this in great detail, but I do remember mainly telling you about redrawing without constantly sending redraw-messages to yourself (yet properly walking the rectangle list, and locking the screen using wind_redraw()). Basically you save the latency associated with message passing in the AES. You definitely objected to this approach.
Basically:
1. Lock screen (wind_update)
2. Do your stuff, but do it properly (walk rectangle list)
3. Unlock screen (wind_update)
I also suggested that if the response from WF_FIRSTXYWH equals the dirty area, there is no need to proceed with a 2nd call to WF_NEXTXYWH, or to check for intersections, you can then just spew your window content to screen. Basically you save 1 call to the VDI.
Basically (screen is supposed to be locked when you're doing this):
1. WF_FIRSTXYWH
2. response equals dirty are? Go to 4.
3a. redraw by following rectangle list (since there are obviously more entries)
3b. redraw without using rectangle list (since there are no more entries anyway)
Maybe this is where we didn't understand each other, because this is my definition of a non-blocked window. A non-blocked window is often on top, but a topped window might be blocked.
I do not considere any of this to be "experimental". If my suggestions were wrong, it would be great to know more about it. Does Conholio suffer from similar redraw problems? (because if I've suggested something, it's guaranteed to be used in Conholio...).