[Fwd: Re: Possible bug to do with scrolling and xgps]

[Adam Fedor]

I don't have time to look at this right now, but if someone else does,
be my guest. I might have time next week...

My thoughts, which may or may not be correct:
----------------------------------------------------------------
The bounding box coordinates are only updated during a lockFocus, so we
need to make sure it's updated when the view is already lock focused.

THe odd thing is that I think it is the NSClipView's coordinates that
are changed, but the _document_view needs to know about it, so  in the
NSClipView's method to set the bounding box, there needs to be something
like:

 if (_document_view == [NSView focusedView])
   update coordinates (as in [NSView -lockFocus]).

---------------------------------------------------------------------

-------- Original Message --------
Subject: Re: Possible bug to do with scrolling and xgps
Date: Tue, 31 Oct 2000 23:08:48 +1300
From: Stephen Brandon <VaryaAndSteve@brandons.free-online.co.uk>
To: Adam Fedor <fedor@doc.com>
References: <00103023241300.02528@tokyo.brandon.com>
<39FE528A.F7329F28@doc.com>


--Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 31 Oct 2000, you wrote:
> Stephen Brandon wrote:
> > If you can confirm that this is a bug (and I am sure it is), and if =
you can
> > tell me the sort of places where a fix needs to be done in GNUstep, =
I would be
> > happy to have a go at fixing it myself. Though it might be easier =
if you did
> > it, if you know all the frameworks really well.
> >=20
>=20
> I can't really confirm it's a bug, because I haven't seen it. It =
would
> be helpful if you could make a small test app that shows the problem. =
In
> any case, the best place for this besides gnats is =
bug-gnustep@gnu.org
>=20

Hi,

I've hacked together a small app with portions of my production code, =
which
shows the problem quite nicely, though the code looks pretty awful!

If you compile the app as given, the bug has a workaround, so you can =
see what
is supposed to happen when there is no bug. The app has a simple view =
of a
diagonal line in a scroll view, and you can click and drag left and =
right to
highlight part of the line. You can extend the selection with the shift
=
key.

THE BUG
To see the bug in action, comment out line 2 of TestView.m. This causes
=
the
removal of the 2 lines of code which are the workaround.

The workaround simply unlocks then locks focus JUST BEFORE the =
highlighting is
done. This causes the updated coordinates of the TestView to be taken =
into
account in the highlighting. Otherwise, if you drag off the right of =
the view,
then reverse direction and drag left again, the right edge of the =
highlighted
rectangle lags behind the mouse position, by the amount that the view
originally scrolled to the left. In other words, the unhighlighting is =
drawn on
the screen in the position it would have done if the view had NOT =
scrolled.

So, it is evident from this test that the frame relationships between
containing views are only updated in the XGContext when the focus is =
changed. I
have had this exact code running on OpenStep for a long time, and the
workaround is NOT necessary on OpenStep. Therefore, GNUStep bug? :-)

I am sorry that the mouse dragging code is quite complex and =
unreadable. It's
worse than really necessary for this example, because it comes from the
=
SndKit
framework for displaying sounds, where there are issues to do with all =
kinds of
magnification, and exact pixel/sample relationships that must be =
absolutely
accurate.

Something that shows up on my system (and probably will on yours) is =
that the
dragging performance is not all that good. OK, there's lots of =
debugging printf
nonsense in the code I sent you, but apart from this, when scrolling =
there are
frequently artifacts that take a few seconds to sort themselves out, =
and look
quite bad on screen. I trust that this will improve in future!

Anyway, I really hope all this helps.

Stephen Brandon
stephen@pyrusmalus.com

LinuxTest.tar.gz
Description: GNU Zip compressed data