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 <[EMAIL PROTECTED] > 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> _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
