NSTextView field editor redrawing weirdness

  • I'm using a custom field editor in a few different windows. Normally,
    the field editor only performs draws when the text is changed or the
    caret drawing timer goes off. However, in one of my views, the field
    editor constantly redraws the entire text view whenever the caret
    drawing timer goes off.

    When I break on -setNeedsDisplayInRect: inside the text view, the
    caret timer is forcing a redisplay at the exact spot where the caret
    is located with a width of 1. So far, so good. The problem is, when
    the NSView superclass method is called, something inside the AppKit
    is stretching the rectangle to cover the entire view. It's only
    happening in one view, and I don't see anything noticeably different
    in that one view.

    I also tried breaking on -
    setNeedsDisplayInRect:avoidAdditionalLayout: and confirmed that the
    second argument is always NO. So what in the world could be causing
    this behavior, and how do I stop it?

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • On Oct 16, 2006, at 1:07 PM, Nick Zitzmann wrote:

    > I'm using a custom field editor in a few different windows.
    > Normally, the field editor only performs draws when the text is
    > changed or the caret drawing timer goes off. However, in one of my
    > views, the field editor constantly redraws the entire text view
    > whenever the caret drawing timer goes off.
    >
    > When I break on -setNeedsDisplayInRect: inside the text view, the
    > caret timer is forcing a redisplay at the exact spot where the
    > caret is located with a width of 1. So far, so good. The problem
    > is, when the NSView superclass method is called, something inside
    > the AppKit is stretching the rectangle to cover the entire view.
    > It's only happening in one view, and I don't see anything
    > noticeably different in that one view.
    >
    > I also tried breaking on -
    > setNeedsDisplayInRect:avoidAdditionalLayout: and confirmed that the
    > second argument is always NO. So what in the world could be causing
    > this behavior, and how do I stop it?

    Does the field editor contain only one line of text, or more than one
    line?  NSTextView has an optimization that will cause it to redraw
    only a small rect around the insertion point caret if it thinks that
    it can do so correctly and efficiently, but it reserves the right to
    redraw the entire line of text if it chooses, and it will choose to
    do so under some circumstances.  The list of those circumstances is
    long and changes from release to release, but it includes criteria
    related to view scaling and positioning, among other things.  In many
    circumstances there is actually little performance difference between
    the two cases.

    Douglas Davidson
  • On Oct 16, 2006, at 2:14 PM, Douglas Davidson wrote:

    > Does the field editor contain only one line of text, or more than
    > one line?

    It contains only one line.

    > In many circumstances there is actually little performance
    > difference between the two cases.

    Performance isn't actually the problem. The problem is I have some
    background views that are placed in close proximity to the text view,
    and every time the text view completely redraws itself, it ends up
    drawing its background color over the top of the background views,
    which doesn't look good. Turning off drawing the background solves
    the problem, but then the text from the original text field isn't
    overwritten, so it looks like the user is writing over the top of the
    text. Is there any way of knowing when the text view is going to
    completely redraw itself, and if so, then what do I need to do? I
    suppose I could move the views out of the way if it happens... Of
    course, I'd prefer for it not to happen.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • On Oct 16, 2006, at 1:23 PM, Nick Zitzmann wrote:

    > Performance isn't actually the problem. The problem is I have some
    > background views that are placed in close proximity to the text
    > view, and every time the text view completely redraws itself, it
    > ends up drawing its background color over the top of the background
    > views, which doesn't look good. Turning off drawing the background
    > solves the problem, but then the text from the original text field
    > isn't overwritten, so it looks like the user is writing over the
    > top of the text. Is there any way of knowing when the text view is
    > going to completely redraw itself, and if so, then what do I need
    > to do? I suppose I could move the views out of the way if it
    > happens... Of course, I'd prefer for it not to happen.

    When the text view causes the line with the insertion point to be
    redrawn, it does so by the normal setNeedsDisplay... mechanism.  If
    you have something that doesn't work well with that--overlapping
    sibling views, for example--then that would seem to be the source of
    the problem.

    Douglas Davidson
  • On 16 Oct 2006, at 23:45, Douglas Davidson wrote:

    >
    > On Oct 16, 2006, at 1:23 PM, Nick Zitzmann wrote:
    >
    >> Performance isn't actually the problem. The problem is I have some
    >> background views that are placed in close proximity to the text
    >> view, and every time the text view completely redraws itself, it
    >> ends up drawing its background color over the top of the
    >> background views, which doesn't look good. Turning off drawing the
    >> background solves the problem, but then the text from the original
    >> text field isn't overwritten, so it looks like the user is writing
    >> over the top of the text. Is there any way of knowing when the
    >> text view is going to completely redraw itself, and if so, then
    >> what do I need to do? I suppose I could move the views out of the
    >> way if it happens... Of course, I'd prefer for it not to happen.
    >
    > When the text view causes the line with the insertion point to be
    > redrawn, it does so by the normal setNeedsDisplay... mechanism.  If
    > you have something that doesn't work well with that--overlapping
    > sibling views, for example--then that would seem to be the source
    > of the problem.

    Yes, you're not supposed to have overlapping views.  Cocoa doesn't
    support them yet and you will get strange drawing issues like that.

    Mike.
    >
    > Douglas Davidson
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/mike.abdullah%
    > 40gmail.com
    >
    > This email sent to <mike.abdullah...>
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today