FROM : Benjohn
DATE : Wed Nov 24 12:53:25 2004
I posted in the last few days (issue 313, message 15) about a display
problem in our application. It seemed that some rectangle invalidations
sent with "setNeedsDisplayInRect:" were being ignored.
I had another look at our display problem yesterday, and I have managed
to "fix" it by avoiding using "setNeedsDisplayInRect:" and instead
using "displayRect:". Calling this render methods directly is not the
correct approach [1], but as well as solving our immediate problem,
this proves (I think) that there definitely is an issue with
"setNeedsDisplayInRect:". The method is forgetting some of the
rectangle invalidations that are sent to it.
The Apple's documentation of "needsDisplay" somewhat implies that any
display method will clear the state that remembers that a display is
needed:
> needsDisplay
>
> - (BOOL)needsDisplay
> Returns YES if the receiver needs to be displayed, as indicated using
> setNeedsDisplay: and setNeedsDisplayInRect:; returns NO otherwise. The
> displayIfNeeded... methods check this status to avoid unnecessary
> drawing, and all display methods clear this status to indicate that
> the view object is up to date.
There's scope for this going wrong in a multithreaded application,
certainly, and we are calling "setNeedsDisplayInRect:" from a thread
other than the main thread, but Apple say:
> If a secondary thread of an application wants to cause portions of the
> view to be redrawn on the main thread, the normal mechanisms work:
> setNeedsDisplay:, setNeedsDisplayInRect:, and setViewsNeedDisplay:. An
> explicit call to the NSView method display on a secondary thread will
> be treated as if it were a call to setNeedsDisplay: with an argument
> of YES, and the display will be done on the main thread.
Before I make time to build a small project that isolates this problem,
I'd like to know that I'm not doing something stupid :) I have called
"setAutodisplay: YES" on the parent window, but I can't see anything
else that I should do to coerce display updates in to life.
To summarise:
Do I seem to be missing something?
Is there a known problem with setNeedsDisplayInRect?
Thanks very much,
Benjohn
[1] I've heard this said many times. It's incorrect (I believe) because
it is inefficient; it leads to more redraws than there ought to be. I
don't think it's actually dangerous though? I've used quartz debug to
have look at the overdraw penalty we're suffering now, and it's not
actually all that bad.
DATE : Wed Nov 24 12:53:25 2004
I posted in the last few days (issue 313, message 15) about a display
problem in our application. It seemed that some rectangle invalidations
sent with "setNeedsDisplayInRect:" were being ignored.
I had another look at our display problem yesterday, and I have managed
to "fix" it by avoiding using "setNeedsDisplayInRect:" and instead
using "displayRect:". Calling this render methods directly is not the
correct approach [1], but as well as solving our immediate problem,
this proves (I think) that there definitely is an issue with
"setNeedsDisplayInRect:". The method is forgetting some of the
rectangle invalidations that are sent to it.
The Apple's documentation of "needsDisplay" somewhat implies that any
display method will clear the state that remembers that a display is
needed:
> needsDisplay
>
> - (BOOL)needsDisplay
> Returns YES if the receiver needs to be displayed, as indicated using
> setNeedsDisplay: and setNeedsDisplayInRect:; returns NO otherwise. The
> displayIfNeeded... methods check this status to avoid unnecessary
> drawing, and all display methods clear this status to indicate that
> the view object is up to date.
There's scope for this going wrong in a multithreaded application,
certainly, and we are calling "setNeedsDisplayInRect:" from a thread
other than the main thread, but Apple say:
> If a secondary thread of an application wants to cause portions of the
> view to be redrawn on the main thread, the normal mechanisms work:
> setNeedsDisplay:, setNeedsDisplayInRect:, and setViewsNeedDisplay:. An
> explicit call to the NSView method display on a secondary thread will
> be treated as if it were a call to setNeedsDisplay: with an argument
> of YES, and the display will be done on the main thread.
Before I make time to build a small project that isolates this problem,
I'd like to know that I'm not doing something stupid :) I have called
"setAutodisplay: YES" on the parent window, but I can't see anything
else that I should do to coerce display updates in to life.
To summarise:
Do I seem to be missing something?
Is there a known problem with setNeedsDisplayInRect?
Thanks very much,
Benjohn
[1] I've heard this said many times. It's incorrect (I believe) because
it is inefficient; it leads to more redraws than there ought to be. I
don't think it's actually dangerous though? I've used quartz debug to
have look at the overdraw penalty we're suffering now, and it's not
actually all that bad.
| Related mails | Author | Date |
|---|---|---|
| No related mails found. | ||






Cocoa mail archive

