GNOME Bugzilla – Bug 159078
slow highlight
Last modified: 2008-11-29 06:26:59 UTC
on a screen with a lot of text my term seems to hang for a couple seconds before it hightlights anything.. this can range from like 2 or 3 seconds to about 10 seconds.. Can highlight very fast in other apps.. gedit.. firefox..
Can you reproduce this with later releases?
Yes i can with 2.10 and 2.12. The situation has improved since 2.8, that's true. This doesn't happen everytime. As testcase, i do the following : - open a new terminal - dmesg (300 lines) - select the last 15 lines. With uxterm, selection is immediate. With gnome-terminal, it takes from 0.5s to 1.0s to hilight. There are also rare unreproducable cases with buffer with a lot text in where hiliting can still take 20.s or 3.0s.
cannot reproduce with GNome 2.14 highlighting takes place immediateley are you running a very slow machine?
Define slow. Even if i add a 500MHz computer, it should be enough to hilite some text as i would be able to play Quake 3 @ 60fps on it. So no, i have 1GHz ppc and a 2GHz P4. It happens with terminal with full scrollback and especially in full screen
I can confirm this. Is not predictable and takes some time to hit it, but I do from time to time.
I suspect that vte's past behaviour of clearing and restoring the highlight (triggering a window invalidate) would not have helped. Also bug 324246 seems relevant.
I can't reproduce this. Behdad, Benoît, tom: have you seen this lately? Note that bug 324246 was particularily noticeable when there were lots of URLs in the screen.
Reproducible with long lines
Benoit, just so I'm clear on the specifics - do you mean selecting within a wide terminal or where a single line spans many rows?
exactly. full screen terminal ~ 140x40 long lines, lines that wrap. like dmesg | tr -d "\n"
I can reproduce this by making a terminal huge, saying «dmesg | tr -d "\n"», and trying to select the end of the output. Details, details, details! ;-)
sysprof indicates that it's the vte_terminal_hilite_match() which is consuming all the cycles. We can improve things slightly by not updating the match during the selection-drag, and other tricks to reduce the number of times we recheck the match. However, we will always suffer at least one regex search before the button-click is processed.
For kicks, I've committed this to vte:- r1739: 2007-02-24 Chris Wilson <chris@chris-wilson.co.uk> Bug 159078 – slow highlight Do not update the match hilite during a selection-drag. Record unsuccesful regex matches, so we can quickly determine whether the cursor is still inside the blank region. * src/vte-private.h: * src/vte.c: (vte_terminal_match_check_internal), (rowcol_inside_match), (vte_terminal_match_check), (_vte_terminal_set_pointer_visible), (vte_terminal_match_hilite_clear), (vte_terminal_match_hilite_show), (vte_terminal_match_hilite_hide), (vte_terminal_match_hilite_update), (vte_terminal_match_hilite), (vte_terminal_motion_notify), (vte_terminal_button_press), (vte_terminal_focus_in), (vte_terminal_focus_out), (vte_terminal_enter), (vte_terminal_leave), (vte_terminal_init), (vte_terminal_unrealize), (vte_terminal_draw_rows), (vte_terminal_paint):
->vte
Can't reproduce anymore. Scrolling is still slow with such long lines, but selection is normal.