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
NSTrackingAreaOptions opts = (NSTrackingMouseEnteredAndExited |
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
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
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,
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
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
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.
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
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
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
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
11 matches
Mail list logo
