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

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

On Mon, 15 Dec 1997, Owen Taylor wrote:

> 
> Raph Levien <raph@acm.org> writes:
> >
> > On Sun, 14 Dec 1997, Owen Taylor wrote:
> > 
> > > 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. 
> > 
> > I had another thought on this and wanted to throw it out there. Since 
> > this is at heart a race condition caused by asynchronous GraphicsExpose 
> > events following XCopyArea, wouldn't the problem be fixed by doing an 
> > XSync right before the scroll? I can't imagine the performance 
> > degradation would be that serious, and it sounds a whole lot simpler 
> > than some of the other proposals.
> 
> I don't think this will help. XSync (or gdk_flush()) only affect
> the output queue. Since the problem is GraphicsExpose events sitting
> in the input queue, the only way to fix it is to process those events
> before doing the XCopyArea.

i have the same problem in gemvt (TODO):
GtkTerm:
*       area copying relys on expose events, but they appear asyncronous
        ex.: move GtkTerm have a line out of the screen an do ls / -R
        
so, have you had any experience with backing store in this case?
i mean drawing in an unvisible window and copying from there into the
scroleld one?
i think i'll just do the exposes on my self, as the scrolling code normaly
knows what got obscured, it can just forgo the x servers expose events.

> 
> Regards,
>                                         Owen

---
ciaoTJ