Possible CopyArea Corruption With gtkclist.
- From: ralph inputplus demon co uk
- To: gtk-list redhat com
- Subject: Possible CopyArea Corruption With gtkclist.
- Date: Tue, 11 Aug 98 14:47:35 +0000
Hi,
I've been having some problems with some of my own X code and looked
towards gtk+-1.1.1's gtkclist.c for inspiration but it might have the
same problem.
The problem with vadjustment_value_changed using a CopyArea request to
shift part of the list when scrolling is you can't be sure that of the
state of the source area that is being copied. I understand the use of
check_exposures and gdk_event_get_graphics_expose in processing any
GraphicsExpose or NoExpose events that may result from the CopyArea but
this doesn't always seem sufficient. Here's an example.
1. The list window is partially obscured by another window which
is then removed. The server generates an expose event that starts
winging its way towards the client.
2. Meanwhile, the list decides to scroll and issues a CopyArea
request which happens to intersect with the area that has been
exposed (but hasn't been redrawn yet). It then waits for either
one or more GraphicsExpose events or a NoExpose event on that
window.
3. The server processes the CopyArea request and sends a NoExpose
event in reply. Unfortunately, part of the source area contained
nothing but the background colour and that has now been copied.
4. The list receives the NoExpose event. It then sends requests
to redraw the new blank area that has been scrolled into.
5. The expose event is processed by the list; requests are sent
to redraw the rows in the exposed area.
The end result is that the list now contains an area that was copied
before its contents were valid, but since it wasn't obscured when the
CopyArea was processed, no GraphicsExpose events were generated for
it.
This can happen in my own client which happens to have a structure very
similar to gtkclist.c. I haven't tried with an actual gtkclist but
can't see any reason why this shouldn't also suffer the same problem.
Can anyone explain why this isn't a problem with the gtkclist widget?
I can't see a solution that copes with all cases.
Thanks,
Ralph Corderoy.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]