#664 Slow scrolling

open-rejected
Scintilla (793)
1
2008-03-18
2008-03-14
Anonymous
No

This bug has already been posted, but I don't know, whether you read my last remark. Please comment, here it is again:

Scrolling with the mouse wheel is fine as is scrolling with the scroll bar. If I press the down-button of the scroll bar, it scrolls line by line and performance is fine too. However, scrolling line by line **by pressing the "down-arrow" key on my keyboard is horribly slow**. So I guess this bug is not hard to fix as scrolling in the general case is fast enough.

Discussion

  • Neil Hodgson

    Neil Hodgson - 2008-03-14

    Logged In: YES
    user_id=12579
    Originator: NO

    Duplicate of #1911857.
    I didn't reply to your last message as I could not think of a useful response.
    I don't understand why you believe that this issue is "not hard to fix" and hope that is cleared up when you send in a patch.

     
  • Neil Hodgson

    Neil Hodgson - 2008-03-14
    • priority: 5 --> 1
    • assigned_to: nobody --> nyamatongwe
    • status: open --> open-duplicate
     
  • Andreas Rumpf

    Andreas Rumpf - 2008-03-15

    Logged In: YES
    user_id=807859
    Originator: NO

    The bug seems to be in Editor::EnsureCaretVisible(). Probably it calls "Redraw" too often. I don't have a fix. Can you help?

    Fact is:

    void Editor::CursorUpOrDown(int direction, selTypes sel) { // HORRIBLE PERFORMANCE
    Point pt = LocationFromPosition(currentPos);
    int posNew = PositionFromLocation(
    Point(lastXChosen, pt.y + direction * vs.lineHeight));
    if (direction < 0) {
    // Line wrapping may lead to a location on the same line, so
    // seek back if that is the case.
    // There is an equivalent case when moving down which skips
    // over a line but as that does not trap the user it is fine.
    Point ptNew = LocationFromPosition(posNew);
    while ((posNew > 0) && (pt.y == ptNew.y)) {
    posNew--;
    ptNew = LocationFromPosition(posNew);
    }
    }
    MovePositionTo(posNew, sel); // calling this with MovePositionTo(posNew, sel, false) improves performance!
    // so the bug has to be in Editor::EnsureCaretVisible(). Or am I missing something?
    }

    void Editor::ScrollTo(int line, bool moveThumb) { // FINE PERFORMANCE
    int topLineNew = Platform::Clamp(line, 0, MaxScrollPos());
    if (topLineNew != topLine) {
    // Try to optimise small scrolls
    int linesToMove = topLine - topLineNew;
    SetTopLine(topLineNew);
    ShowCaretAtCurrentPosition();
    // Perform redraw rather than scroll if many lines would be redrawn anyway.
    #ifndef UNDER_CE
    if ((abs(linesToMove) <= 10) && (paintState == notPainting)) {
    ScrollText(linesToMove);
    } else {
    Redraw();
    }
    #else
    Redraw();
    #endif
    if (moveThumb) {
    SetVerticalScrollPos();
    }
    }
    }

     
  • Neil Hodgson

    Neil Hodgson - 2008-03-15

    Logged In: YES
    user_id=12579
    Originator: NO

    I do not know how to fix this either.

     
  • Andreas Rumpf

    Andreas Rumpf - 2008-03-15

    Logged In: YES
    user_id=807859
    Originator: NO

    Does each Redraw() call *request a redraw* or *a real redraw*? If it does a real redraw, I have an idea how to fix.

     
  • Andreas Rumpf

    Andreas Rumpf - 2008-03-15

    Logged In: YES
    user_id=807859
    Originator: NO

    And what exactly does it redraw? The whole text widget? A small specified rectangle?

     
  • Neil Hodgson

    Neil Hodgson - 2008-03-16

    Logged In: YES
    user_id=12579
    Originator: NO

    To find out what Redraw does, read its code in Editor::Redraw which calls InvalidateRectangle over the client area. InvalidateRectangle is defined for each platform and for GTK+ it calls gtk_widget_queue_draw_area. You could also investigate by running inside a debugger and stepping through the relevant code.

     
  • Nobody/Anonymous

    Logged In: NO

    After tracing with gdb, I think it is not in Scintilla, but in the interaction with GTK2. Yes, I know you've already known. It seems Scintilla is just too fast requesting redraws, even though one keydown-press results in exactly one redraw (most of the time).
    This is my patch:

    #ifdef PLAT_GTK
    #include <glib.h>
    #endif

    ...

    void Editor::EnsureCaretVisible(bool useMargin, bool vert, bool horiz) {
    ...
    #ifdef PLAT_GTK
    g_usleep(10000); // sleep 10 msecs to allow a process switch in Linux's scheduler
    #endif
    }

     
  • Neil Hodgson

    Neil Hodgson - 2008-03-18

    Logged In: YES
    user_id=12579
    Originator: NO

    The patch will sleep the GTK+ code as well as Scintilla since GTK+ is running on the same thread. It may be giving the X server some more time to work. On my machine, while the patch reduces CPU usage it does so at the expense of performance making what was smooth scrolling choppy and taking around 15% longer.

     
  • Nobody/Anonymous

    Logged In: NO

    Yeah, I know it's a hack. You don't need to apply it. I don't have any better ideas, except maybe running the redraw operation in a separate thread...
    Still wondering why other people don't have this problem...

     
  • Neil Hodgson

    Neil Hodgson - 2008-03-18

    Logged In: YES
    user_id=12579
    Originator: NO

    Most people have faster machines so won't see this. Probably best to just leave this item open so that others will find it and can add their experiences.

     
  • Neil Hodgson

    Neil Hodgson - 2008-03-18
    • status: open-duplicate --> open-rejected
     
  • Nobody/Anonymous

    Logged In: NO

    I have these issues on all of the following machines:
    - Pentium D CPU 3.00GHz, 2GB RAM, nVidia 8600gt
    - AMD Athlon 64 3500+, 2GB RAM, nVidia 8800GTS
    - Intel Core2 Quad Q6600 2.4GHz, 4GB RAM, nVidia Quadro FX 5600

    It only happens when using anti-aliased fonts.
    Other editors like Kate and GEdit don't have the problem.

    I had to revert to using Kate, because this problem makes SciTE unusable, which is a pitty.
    Something as basic as rendering text can't possibly be something that hardware can't handle properly, so it has to be a software problem.
    My guess is that there are some kind of pitfalls in Pango or similar that you have to know how to avoid in order to get acceptable performance.

     
  • Nobody/Anonymous

    Experiencing this as well, but only on Fedora. Windows version is fine.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks