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

[Owen Taylor <owt1 cornell edu>]

> > After the XCopyArea call, X thinks that the entire window now contains
> > valid information (for the purpose of calculating GraphicsExpose
> > events). But actually, that isn't true until the GraphicsExpose events
> > filter through the queue. Before then, X has blanked out the improper
> > areas to the background color (*) If another motion event occurs
> > before then, X will copy the blanked out areas, but not produce
> > graphics expose events for them, thus leading to the observed gray
> > bars. 
> 
> Umm. This sounds like a serious problem.

Yes, it is.

> > I'm thinking of adding a specialized function to gdk to handle this:
> > 
> >   gdk_get_next_graphics_expose_event (GdkWindow *window, GdkEvent
> >                                       *event, gint status);
[ ... ]

> I still see the race condition - specifically, two XCopyArea's in a row 
> before the GraphicsExpose from the first one makes it to the app. This 
> seems to be a general consequence of the asynchronous coupling between 
> the X client and server.

The idea is that gdk_get_next_graphics_expose_event 
(this_function_name_will_give_you_tendinitis) looks through the
event queue using XCheckIfEvent, which flushes the output buffer.
If you call this immediately after the first XCopyArea, then I think
the GraphicsExpose events from that CopyArea call should be found
before control returns and the next CopyArea call can be processed.

> > People who knew what they were doing could still specify that they
> > wanted GraphicsExpose events. But it would remove a trap for
> > beginners, and cut down on the number of NoExpose events GTK handles.
> 
> Ok, so the rule is: if you do XCopyArea within a window, you'll want to 
> turn on GraphicsExpose, right?

Yes. Since the user already has to be aware of the above trap and
handle it, I don't think it is much of a burden.

[ Re: difference between using XCopyArea and scrolling an X window ]

> > The same latency should be present in any case, right? X should
> > optimize scrolling the window like using XCopyArea, and the
> > GraphicsExpose events also have to go round-trip. 
> 
> No, what I'm saying is that the scroll-in areas are drawn directly by the 
> app right after the XCopyArea, without any GraphicsExpose events. The 
> only time the latter become relevant is when the window is partially 
> exposed, a rare enough case that I don't care about the slight 
> performance problem.

Ah, yes. You're right.

Regards,
                                        Owen