[Mono-winforms-list] Scrolling performance isues

[Chris Toshok]

Nice. That look pretty good, with the only issue being performance  
over an X connection with high latency - it'll block all UI until the  
redraws complete.

That said, it's definitely better than what we have now :)

toshok

On Aug 7, 2008, at 12:17 PM, Carlos Alberto Cortez <calberto.cortez at gmail.com 
 > wrote:

>
> 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.
> Carlos.
>
> PD - The patch is a test, so needs to be beautified still ;-) But  
> should
> work.
> <xplatx11-changes.patch>