Re: [Testcase] Re: 32bit scrolling problems in Gtk+ 1.3.1



I think I've found the problem.  gdk_window_gravity_works () was
returning no, y was equal to 20 instead of -20.  I'm pretty sure positive
20 is correct because the parent window will be offset -20 and the
child should stay the same place visually.  So doing a:

-      gravity_works = ((y == -20) ? YES : NO);
+      gravity_works = ((y == 20) ? YES : NO);

in gdk_window_gravity_works () should fix that part of the problem.

The second part is that performing scrolling when gravity_works = NO
causes flicker, assuming an attempt is being made for buggy X servers.  I
tried running ./gtkfoo --sync, and while it flickers, ultimately it will
update the scrolling window properly.  So I'm guessing a gdk_flush () is
needed somewhere.

- David

On 6 Sep 2000, Owen Taylor wrote:

> 
> "David A. Bartold" <foxx mail utexas edu> writes:
> 
> > Thanks, it fixed the BadValue problem.  There are still
> > problems when the window is initially small and then resized to
> > something big (could be an X server problem?) and the scrolling
> > occurs between begin+16384 and end-16384 of the full length,
> > but for now I've gotten around it by creating the window large
> > (i.e. >15 bits).
> 
> Sigh. 
> 
> You are saying that if, in your test case, you set the initial size to
> 1, and then you go to the middle of the scrolling area, and scroll
> left and right, you see obvious misbehavior?
> 
> I don't see that here. (XFree86-4.0.1). It's conceivable that
> it could be an X server problem. What X server are you using?
> 
> Could you modify x11/gdkwindow-x11.c/gdk_window_gravity_works() to
> print out its result and see what that is? I haven't implemented
> the fallbacks yet on the theory that its just bug workarounds
> for old servers, and until something fails, probably nobody
> is using such old servers.
> 
> Regards,
>                                         Owen
> 
> 





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]