Re: Cursor tracking rects
Re: Cursor tracking rects
- Subject: Re: Cursor tracking rects
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 29 Dec 2001 13:28:00 -0500
On Saturday, December 29, 2001, at 11:25 AM, email@hidden.
com wrote:
That's what stumped me, then, when I tried to do it. I thought it so
obvious that the cursor rects should be calculated once for the whole
view, and that the scroll view would automatically clip and compensate
for that, that I refused to consider any other alternative :-)
Shouldn't we file a bug on that? Recalculating the rects after every
scroll is inefficient and inconsistent with other behavior (for text
inside a scroll view).
It isn't really a bug; the assumption of the underlying View subsystem
is that a scroll-- or anything else that causes the view to redraw-- can
trigger a change in the imaging that will cause the old cursor rects to
become invalid. It is left as an exercise for the developer to
optimize for the simple case of one text container, one layout manager and
one clipped visible rectangle.
While convenience API to handle the simple case would be nice,
recalculating the cursor rects after a scroll isn't that inexpensive if
the calculations are constrained to the visible range.
A better explanation and/or example of handling cursor rect calculations
in the context of a clipview/scrollview combination would be extremely
welcome, though (I have file a feature enhancement request for exactly
that).
I think it may be that at the time of the first display, the text view
isn't fully laid out yet, so calling glyphRangeForBoundingRect will
return invalid data. (I ran into this several times when trying to scroll
to someplace in the middle). You need to figure out some call to lay out
the whole view first, if it isn't already. I forget what I used, but I
didn't like it.
-glyphRangeForBoundingRect: will cause the layout manager to generate the
glyphs and perform all necessary operations such that it calculates the
correct rectangles. There is a second method that is implemented
explicitly NOT to cause the additional work to be done, if it hasn't
already.
Further analysis reveals that the whole cursor rect calculation stuff isn'
t happening *at all* after the first render. I'm not sure why.
(From Xmanview): I do the following. The
-generateManPageDataForQueryString: method takes care of generating all of
the attributed text, passing it off to the text view, etc..
[self generateManPageDataForQueryString: queryString];
/* above causes this:
[[manView textStorage] setAttributedString: newString];
[manView scrollPoint: NSMakePoint(0,0)];
[manView setNeedsDisplay: YES];
*/
[[manView window] invalidateCursorRectsForView: manView];
[window makeFirstResponder:manView];
However, the cursor rects are not calculated until the view is either
scrolled or resized. I don't know why.
There is also a bug with cursor tracking rects; if the tracking rect is
right at the border of the text/scrollview, then the cursor will not
always change as the mouse goes over that rect coming from outside the
view. If I can figure out a way to generate a fairly minimal example, I'
ll file a bug (I'll probably file one anyway).
b.bum