Re: [gtk-list] Re: GraphicsExpose (was Re: About the About Box)

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

On Tue, 16 Dec 1997, Raph Levien wrote:

> > The example I posted a reference to earlier does this by calling
> > XIfEvent - I may have implied that it was using XCheckIfEvent,
> > which would be incorrect, as you point out. (Another reason why
> > using the current gdk_event_get() doesn't work)
> > 
> > > If I'm right about this, then it seems that there's just no way to scroll 
> > > without at least one roundtrip to the server :(
> > 
> > Pretty much. One could keep a flag when waiting for an GraphicsExpose
> > /NoExpose event, batch up events that cause further scrolling, and then
> > execute them when the GraphicsExpose event is received. Not much
> > fun to implement though.
> 
> Another idea occurred to me today. Instead of trying to make the 
> GraphicsExpose events effectively synchronous with the XCopyArea call 
> (which is essentially what's been discussed), why not glory in the 
> asynchronity of it all? Basically, here's what I'm proposing:

i've been also thinking about this approach for a few days now... ;)

> 1. Every time you do an XCopyArea call, add the parameters to a queue. I 
> think the rectangle and the offset should be sufficient.
> 
> 2. Every time you get a GraphicsExpose event with a count of zero, or a 
> NoExpose event, you remove one entry from the queue.

you need to keep track of the time to interrelate the exposes whith
the XCopyArea calls.

> 3. Translation of GraphicsExpose events filters through the queue. I.e. 
> if you get a GraphicsExpose event in a region that's been moved by a later
> XCopyArea, then just offset the corresponding Expose event that's pushed
> through Gdk. 

actually, to interprete  the expose events correctly, it should go something
likes this:

1. [no expose events queued anymore]
2. XCopyArea call, save it's parameters, time1
3. XCopyArea call, save it's parameters, time2
4. expose events arrive
4. for exposes before time1 do nothing.
   exposes from after time1 need to be adjusted, by moving their
   rectangles if inside the rectangle from 2.
   exposes from after time2 need to be adjusted, by moving their
   rectangles if inside the rectangle from 3.
5. handle adjusted expose events, if they still contain a rectangle
   that intersects with the window.

> It shouldn't bee too hard to see that this solution is correct, 
> reasonably efficient (no XSync's ever), and doesn't require significant 
> modification to Gtk's event handling code. Further, I don't think it's 
> that complex to implement.

i think this approach would just require some
gdk_window_mark_scroll_area(window, time, rectangle, difference)
gdk_window_expose_event_adjust(window, expose_event)


the only problem i see is, will Xlib provide us with a current time
that relates to the current time of the x server?


> Raph
> 

---
ciaoTJ