[Mono-winforms-list] Scrolling performance isues

Carlos Alberto Cortez calberto.cortez at gmail.com
Thu Aug 7 15:17:44 EDT 2008

Hey Chris

Comments below.

> I'm also not sure flushing the paint queue before doing the XCopyArea
> (suggestion 1 above) will be enough either.  It's very easy to imagine
> a scenario where you're scrolling and we do another ScrollWindow
> before all the GraphicsExpose events have been received.  We really do
> need to block things somehow.  And it'll be more than just blocking
> the message queue - we'll need to actually stop the thread if there's
> a call to ScrollWindow (or anything else that ends up copying) until
> the GraphicsExposes have been handled.

I went and began to review our code and wondering how to do it the
proper way - then went to Gtk+ scrolling code once more, and then could
see that the gtk textbox was handling the scroll itself (it seems the
algorithm is what's called 'smooth scrolling', not sure). 

The idea is that after each request to scroll, they call XIfEvent to
wait for GraphicsExpose/NoExpose events on the scrolled window, blocking
the thread until they get one of them (so you can invalidate or exit the
loop), and adding a expose operation on the window.

I implemented this today for our implementation and it seems to work
just fine, and it seems it follows your idea ;-)

Take a look and tell what you think.

PD - The patch is a test, so needs to be beautified still ;-) But should
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xplatx11-changes.patch
Type: text/x-patch
Size: 4412 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-winforms-list/attachments/20080807/f4ba2d77/attachment-0001.bin 

More information about the Mono-winforms-list mailing list