Hey, The new code that detects not visibles areas of the window to scroll (obscured by other mwf windows or x11 top level ones), although working fine, is somewhat slow, as some people have noticed.
After some research, I found that getting all the child windows for the root window (using XQueryTree on RootWindow, this is, top level windows) is the hot spot, and was causing the slow down. And after some more research in other graphics tool kits, found that: * Most of them make use of GraphicsExpose event, handling it by directly generating expose events or invalidating the area pointed by GraphicsExpose (Gtk+ as far as I know, and also Ivan told me other frameworks do that). And also, regarding our code: * When using composite (Xgl or similar) it's not necessary to do this detection, since the window manager (*it seems*) is doing something that somehow already knows which areas need to get an expose event (in other words: only mwf overlapping detection is needed, not for x top level windows). * The new code, at least in my laptop, without using composite, seems to work fine (no performance lost), and don't know if it's because XQueryTree on RootTree returns a minor number of windows (61 with no composite, instead of 89 with composite, using 5 terminals and a gtk+ application, for example). So, it seems that we should actually handle GraphicsExpose (which all it involves) *or maybe* try to detect if we are using composite - if we are, simply don't use this new code, but just do simple calculations, and if we are not using it, do the detection, since it won't harm the performance. But I woould like people to tell me how this code (2.0 branch or trunk) behaves for them, in both cases (since I remember that Ivan was having performance problems with the new code even without using composite). Hope it's clear ;-) Carlos.
_______________________________________________ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list