On Jun 25, 2008, at 11:57 PM, Quincey Morris wrote:
These statements are a bit puzzling. What does "redrawing" mean here? Are you talking about what you do inside drawRect:, or what you do to cause drawRect: to be invoked? Are you using setNeedsDisplay: or setNeedsDisplayInRect: to trigger drawing, or some other technique?
Redrawing means setting needsDisplay. I'm using
if (![self needsDisplay]) {
[self setNeedsDisplayInRect:rect];
}
I found the needsDisplay check to speed it up a little. rect is the
tracking area.
If you literally meant "the mouse is being dragged", you weren't getting mouseEntered events (they're not sent during dragging unless you ask for them, and you didn't ask for them in your tracking area options) so what was causing drawing to be requested in that case?
The drag starts with mouseDown: and ends with mouseUp:. In between you get mouseDragged: events. Every time such an event arrives, I update the internal selection structure and redraw the view accordingly. It's exactly the same drawing operation that happens when the tracking area messages fire. The same code is executed (using different colors).
If you really "completely disabled redrawing", how were you detecting lag? The lag you started out with was between mouse moving and "redrawing", but if nothing was redrawn ... ?
Instant logging to a NSTextField showing an increasing integer counter. As tracking areas events arrive at the view, the counter is increased and the field is updated. With a higher number (20+) of areas, the counter was not in synch with the mouse movement, increasing its value well after the mouse has stopped. That means that the mouse movement was not in synch with the tracking area event, so tracking area events are delayed for some reason.
I'm wondering whether, even when you've suppressed the drawing of rectangles, you're still flooding the graphics system with setNeedsDisplay... updates, and *that's* what is slowing things down.
Drawing was suppressed, no call to setNeedsDisplay was made in the test. There is no flooding the graphics system, so that's not the case.
P.S. An alternative approach might be to use a single tracking area for your entire custom view, and do your own rectangle hit testing on mouseMoved events that occur inside it.
As I explained in my reply to Graham Cox, the documentation suggests that tracking areas are the way to go. There's no apparent reason for me not to trust the documentation and per se no reason why the system's implementation should be any slower than my own. I'd just be implementing tracking areas myself, checking which rectangle the mouse is in at the moment and firing events accordingly.
It appears that I'll have to do this. It's not a problem of implementation, I was just wondering if there was a reason for it to be lagging.
Also using mouseMoved: events requires you to set setAcceptsMouseMovedEvents: on the hosting window. That means the window has to do something for all views on it when only this one view needs tracking. I thought that was a little overkill. Plus tracking areas are really elegant.
Regards Markus -- __________________________________________ Markus Spoettl
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
