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

[Owen Taylor <owt1 cornell edu>]

> 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:

Just as an initial note - we can't be completely asynchronous - if we
aren't scrolling with PointerMotionHint motion events (which add
partial synchronization) we'll most likely get way behind the user as
usual.

[ description of smart approach mostly omitted ]

> Additionally, if the rectangle intersects with the region outside
> the XCopyArea rectangle, then that area is subdivided into
> rectangles and passed recursively to "filter" without any
> offset. It's the plane with a hole in it, so it can easily be
> subdivided into four rectangles.

If this case was common, it would probably be better to try
to optimize things so that the rectangles are non-overlapping,
since the translated area will often overlap with the non-translated
area. (One would probably want to use some general code for intersecting/
taking the union of rectangles.) It can happen for scrolling, I think
(imagine dragging with the 2nd button in the GIMP and changing
directions on a partially obscured window) - but probably isn't
that common. However, if some areas are getting drawn twice, it
may lead to flashing for some applications.

> To see that this is correct, assume that the GraphicsExpose event 
> rectangles are initially colored purple when the XCopyArea is called. 
> Then, trace through the effect of subsequent XCopyArea calls - they move 
> the purple around. The resulting rectangles may not be minimal, because 
> it's always possible that an XCopyArea will cover over a purple area 
> with non-purple, but optimizing for that is almost certainly more trouble 
> than it's worth. In the common case, there usually won't be a 
> GraphicsExpose event outside the XCopyArea rectantlngle, so the 
> subdivision has a branching factor of one, and the resulting rectangle is 
> exactly the area left uncovered in the Gimp now.
 
> What say the Gtk gods?

I don't think they read this list that much anymore.

As a mere mortal, I currently have (working):

      gdk_draw_pixmap (widget->window,
		       scroll_test_gc,
		       widget->window,
		       ...)

      /* Make sure graphics expose events are processed before scrolling
       * again */
      
      while ((event = gdk_event_get_graphics_expose (widget->window)) != NULL)
	{
	  gtk_widget_event (widget, event);
	  if (event->expose.count == 0)
	    break;
	}

This works and is correct - though it does require the programmer to
know to use this recipe when appropriate.  You're approach sounds
correct, and might give a real performance advantage on slow
networks. I certainly don't have the time to implement it right now -
though if you (or anyone else) want to, go ahead. It would be nice to
have a side-by-side comparison to see if it actually makes a
noticeable difference.

Regards,
                                        Owen