Re: NSTrackingArea message lag
On Jun 25, 2008, at 23:11, Markus Spoettl wrote: I have double (quadruple actually) checked that the redrawing is not the problem, the view draws very quickly. When the mouse is being dragged over the view, the same series of redrawing events is completely instant up to a bar count of more than 200. I've even completely disabled redrawing as a result of tracking area events and the lag is still there. So the drawing is not causing the lag. 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? 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? 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 ... ? 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. 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. ___ 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]
Re: NSTrackingArea message lag
Why do you need to use tracking areas? I doubt that they are designed to handle hundreds of small regions. If you are dragging within the view, just hit-detect the rects yourself and mark them as needing update. If you need that to happen with just the mouse passing over the view (button not pressed) you can turn on mouseMoved: events and do the same thing. Tracking events are awkward at the best of times, and are mostly intended for cursor management. I think you'd find a more conventional approach a lot more fruitful. hth, Graham On 26 Jun 2008, at 4:11 pm, Markus Spoettl wrote: Hello List, I have a custom NSView that draws a number of rectangles of different heights, overlapping 1 pixel on the left and right edge. Each rectangle gets its own tracking area ___ 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]
Re: NSTrackingArea message lag
I'm not saying that's definitely the problem, but to find out for sure you'd need to try both and see how if profiles. Tracking rects are not exactly the same task as testing the rects yourself, because the system has to determine when the mouse actually enters and exits those areas, package the result into an event and dispatch it. It might also be doing this in a way that is constrained by time, or only testing one rect per loop, for example (all of which would be acceptable ways to reduce the event bandwidth for cursor- tracking use). Hit-testing a list of rects within your view should be straightforward, fast and optimised to the task in hand. You didn't say if you were doing this on a mouse drag or a mouse move. If on a drag there is no reason to do anything but your own hit- testing - it will always be much faster than using events. Graham On 26 Jun 2008, at 5:51 pm, Markus Spoettl wrote: On Jun 26, 2008, at 12:19 AM, Graham Cox wrote: Why do you need to use tracking areas? I doubt that they are designed to handle hundreds of small regions. If you are dragging within the view, just hit-detect the rects yourself and mark them as needing update. If you need that to happen with just the mouse passing over the view (button not pressed) you can turn on mouseMoved: events and do the same thing. Tracking events are awkward at the best of times, and are mostly intended for cursor management. I think you'd find a more conventional approach a lot more fruitful. Well, it certainly doesn't sound like that in the guide. There's no indication whatsoever that tracking areas are meant for cursor rectangle updates only, this is just one way to use them. The documentation discourages using mouseMoved: events and encourages use of tracking areas. I can also see why. If I do it using mouseMoved: messages I basically have to do everything that tracking areas provide manually. There is no reason why the system's implementation should be any slower (it's exactly the same task). So, following the documentation, I was convinced that that's the way to go. It appears I stand corrected. Regards Markus -- __ Markus Spoettl ___ 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]
Re: NSTrackingArea message lag
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]
Re: NSTrackingArea message lag
On Jun 26, 2008, at 00:51, Markus Spoettl wrote: On Jun 26, 2008, at 12:19 AM, Graham Cox wrote: Why do you need to use tracking areas? I doubt that they are designed to handle hundreds of small regions. If you are dragging within the view, just hit-detect the rects yourself and mark them as needing update. If you need that to happen with just the mouse passing over the view (button not pressed) you can turn on mouseMoved: events and do the same thing. Tracking events are awkward at the best of times, and are mostly intended for cursor management. I think you'd find a more conventional approach a lot more fruitful. Well, it certainly doesn't sound like that in the guide. There's no indication whatsoever that tracking areas are meant for cursor rectangle updates only, this is just one way to use them. The documentation discourages using mouseMoved: events and encourages use of tracking areas. I can also see why. If I do it using mouseMoved: messages I basically have to do everything that tracking areas provide manually. There is no reason why the system's implementation should be any slower (it's exactly the same task). So, following the documentation, I was convinced that that's the way to go. Tracking rectangles were perhaps mostly used for dealing with cursors. Tracking areas (NSTrackingArea) are useful for more things. The NSWindow documentation used to (and I suppose still does) discourages use of setAcceptMouseMovedEvents. The mouseMoved events generated by tracking areas (NSTrackingMouseMoved option) aren't discouraged, because they only occur upon movement inside the tracking area, and the mouseMoved message is sent directly to the tracking area's owner. You do *not* need to setAcceptMouseMovedEvents:YES to use these tracking area mouseMoved events. You don't even have to test if the event belongs to the view, since you know it does. You just have to do a simple rectangle check to find out which of your rects you hit (and with your original implementation, don't you still have a few lines of code to work out -- from the tracking area in the mouseEntered event -- which rectangle was hit?). Maybe the best way to settle the original question is to profile the performance with Instruments, and find out what's really taking up the time. ___ 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]
Re: NSTrackingArea message lag
On Jun 26, 2008, at 2:01 AM, Quincey Morris wrote: Tracking rectangles were perhaps mostly used for dealing with cursors. Tracking areas (NSTrackingArea) are useful for more things. The NSWindow documentation used to (and I suppose still does) discourages use of setAcceptMouseMovedEvents. The mouseMoved events generated by tracking areas (NSTrackingMouseMoved option) aren't discouraged, because they only occur upon movement inside the tracking area, and the mouseMoved message is sent directly to the tracking area's owner. You do *not* need to setAcceptMouseMovedEvents:YES to use these tracking area mouseMoved events. You don't even have to test if the event belongs to the view, since you know it does. You just have to do a simple rectangle check to find out which of your rects you hit (and with your original implementation, don't you still have a few lines of code to work out -- from the tracking area in the mouseEntered event -- which rectangle was hit?). I must have overlooked the -mouseMoved: feature of tracking areas. I've now changed from multiple tracking areas to one big area covering the entire view. Doing the rectangle checks myself the view is as responsive as expected. Thanks for pointing me in the right direction! Regards Markus -- __ Markus Spoettl ___ 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]
Re: NSTrackingArea message lag
On 27 Jun 2008, at 3:42 am, Markus Spoettl wrote: On Jun 26, 2008, at 4:15 AM, Graham Cox wrote: I think this is your problem. After the first rect is marked as needing update, the needsDisplay method will return YES. That then rejects all subsequent rect marking until the next event loop and the view has been redrawn. Then another rect gets a shot, and so on. Simply removing that if([![self needsDisplay]) should fix your problem, I think. For whatever reason, simply calling -setNeedsDisplay:YES without update rectangle and needsDisplay check is producing the same kind of lag. The view is not updated any faster or more accurately. Granted, the needsDisplay check may be wrong though, I can see the issue there. you can still (and should) use -setNeedsDisplayInRect:, just don't make this conditional on -needsDisplay. I think to really get to the bottom of the delay problem we'd need to see the code in its full context. For example how does your drawRect: method know which rect(s) to repaint? Or does it just go over the whole lot? There could be many reasons why it's slow. Graham ___ 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]
Re: NSTrackingArea message lag
On Jun 26, 2008, at 5:21 PM, Graham Cox wrote: you can still (and should) use -setNeedsDisplayInRect:, just don't make this conditional on -needsDisplay. I think to really get to the bottom of the delay problem we'd need to see the code in its full context. For example how does your drawRect: method know which rect(s) to repaint? Or does it just go over the whole lot? There could be many reasons why it's slow. Unfortunately that's not an option, but it isn't really necessary. I've switched to updating the view from -mouseMoved: events doing my own hit testing and it works very quickly now, there is no more lag. Notice the drawing mechanism didn't change, so the drawing wasn't causing the lag. I have no other explanation than a strange delay in the delivery of tracking area messages. What causes the delay I don't know, it's very likely my fault but it's most definitely not the drawing code. 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]
Re: NSTrackingArea message lag
On Thu, Jun 26, 2008 at 8:41 PM, Markus Spoettl [EMAIL PROTECTED] wrote: Notice the drawing mechanism didn't change, so the drawing wasn't causing the lag. I have no other explanation than a strange delay in the delivery of tracking area messages. What causes the delay I don't know, it's very likely my fault but it's most definitely not the drawing code. Well you've avoided the problem, but you should still remove the condition on -needsDisplay. It's semantically incorrect. --Kyle Sluder ___ 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]
Re: NSTrackingArea message lag
On Jun 26, 2008, at 6:11 PM, Kyle Sluder wrote: Well you've avoided the problem, but you should still remove the condition on -needsDisplay. It's semantically incorrect. I did that (I thought I mentioned that). 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]
