NSRulerView Fast Scrolling Issues

  • Hello,

    I am still trying to perfect the performance of the NSRulerView subclass in my application.  What I know so far is as follows:

    1. the rectangle passed into drawHashMarksAndLabelsInRect: represents the amount scrolled since the last time the rulerview was drawn.  For example, if the user scrolled down by 100 pixels the rectangle would be the bottom 100 pixels of the NSRulerView.

    2. I am not aware of any variable in NSRulerView that represents the scrolling offset of the ruler.  Thus, I am calculating the offset manually based on the size of the rectangle that needs to be redrawn.  Unfortunately when the scrolling amount is greater than the size of the ruler, the rectangle passed in is exactly equal to the size of the RulerView.  As a result the ruler's "scroll offset" (I defined my own variable for this) becomes invalid when scrolling is done very quickly.

    3. I am not aware of any way to communicate directly with the NSScrollView to determine the amount scrolled in a single "frame" of "ruler animation".  I would rather not have to do this, and I expect there should be a way to extract the amount scrolled from the NSRulerView superclass.

    I'll post an update if I manage to solve this problem..  Does anyone have any suggestions?

    Thanks in advance,

    Dave H.
  • On 3 Jan 2008, at 16:36, David Harper wrote:

    > I am still trying to perfect the performance of the NSRulerView
    > subclass in my application.  What I know so far is as follows:
    >
    > 1. the rectangle passed into drawHashMarksAndLabelsInRect:
    > represents the amount scrolled since the last time the rulerview was
    > drawn.

    You can't make that assumption, which is why things aren't working for
    you.  Why do you need to know how much the rulerview has scrolled by?
    The NSRulerView code will already be copying pixels where appropriate
    anyway, so if you're trying somehow to "optimise" drawing, you're
    duplicating system functionality.

    Perhaps you can explain what the performance problem is that you're
    trying to solve?

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • Hi,

    That was exactly the assumption that caused the problems in the first place.  The way I corrected it was by comparing the bounds rectangle of the scroll view's content view before and after the draw method was called.  This gives the correct scroll offset.

    // update the scroll origin based on the amount scrolled
    float dy = curScrollY - [[[self scrollView] contentView] bounds].origin.y;
    curScrollY = [[[self scrollView] contentView] bounds].origin.y;
    scrollOrigin += dy;

    Thanks,
    - Dave H.

    Alastair Houghton <alastair...> wrote: On 3 Jan 2008, at 16:36, David Harper wrote:

    > I am still trying to perfect the performance of the NSRulerView
    > subclass in my application.  What I know so far is as follows:
    >
    > 1. the rectangle passed into drawHashMarksAndLabelsInRect:
    > represents the amount scrolled since the last time the rulerview was
    > drawn.

    You can't make that assumption, which is why things aren't working for
    you.  Why do you need to know how much the rulerview has scrolled by?
    The NSRulerView code will already be copying pixels where appropriate
    anyway, so if you're trying somehow to "optimise" drawing, you're
    duplicating system functionality.

    Perhaps you can explain what the performance problem is that you're
    trying to solve?

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On 3 Jan 2008, at 18:33, David Harper wrote:

    > That was exactly the assumption that caused the problems in the
    > first place.  The way I corrected it was by comparing the bounds
    > rectangle of the scroll view's content view before and after the
    > draw method was called.  This gives the correct scroll offset.

    Indeed, but you still haven't said what you hope to achieve by
    obtaining the scroll offset.  It seems likely that there will be
    another way to do what you want that doesn't involve such a computation.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
previous month january 2008 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