Re: [gtk-list] Re: GraphicsExpose (was Re: About the About Box)
- From: Owen Taylor <owt1 cornell edu>
- To: Raph Levien <raph acm org>
- Cc: gtk-list redhat com
- Subject: Re: [gtk-list] Re: GraphicsExpose (was Re: About the About Box)
- Date: Mon, 15 Dec 1997 19:02:34 -0500
> > 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]