GNOME Bugzilla – Bug 439247
scrolling vim in full screen is painfully slow and takes up 100% of the cpu
Last modified: 2018-02-17 10:43:55 UTC
Please describe the problem: When running gnome-terminal maximized or in fullscreen scrolling on the bottom or the top of vim is painfully slow, and the terminal takes up 100% of the cpu. I've tried numerous fonts with the same results. Xterm and konsole do not have this problem with the exact same fonts. Steps to reproduce: 1. run gnome-terminal 2. run vim inside the terminal 3. open a large file 4. start scrolling down 5. when your cursor hits the bottom of the window and vim starts dragging the entire page for every line you scroll the cpu utilization will go to 100% and the scrolling will be slow. try the same thing in xterm, and it will scroll without issues. Actual results: scrolling in vim is slow Expected results: scrolling should be fast, like xterm or konsole Does this happen every time? yes Other information:
Did some quick xtrace: brought up vim, scrolled down five times. Just grabbed the scrolling traffic. Some stats: [behdad@behdad vte]$ cat vte.trace | grep RENDERRequest | cut -d : -f 6 | cut -d ' ' -f 2 | sort | uniq -c 187 RenderCompositeGlyphs8 22 RenderCreatePicture 21 RenderFillRectangles 22 RenderFreePicture 21 RenderSetPictureClipRectangles [behdad@behdad vte]$ cat xterm.trace | grep RENDERRequest | cut -d : -f 6 | cut -d ' ' -f 2 | sort | uniq -c 38 RenderCompositeGlyphs8 38 RenderFillRectangles [behdad@behdad vte]$ wc -l vte.trace 398 vte.trace [behdad@behdad vte]$ wc -l xterm.trace 138 xterm.trace So, I'm not sure what xterm's doing. Whatever it is, it's different than vte. The traffic doesn't reveal much (I'm not sure, is it doing scrolling by shifting the current window contents? Does vte do that sometimes?) Something I can spot in the xterm traffic is calls like this: glyphs=0x03,0x03,0x03,0x03,0x03,0x03, 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03, 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03, 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03, 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03; }; Those are all space glyphs. Not sure why it's bothering doing that. Anyway, Chris, want to tackle this? Seems like there's something we can do here. xterm is really faster in vim.
Behdad, do you mind checking the perf/vim.sh script and see if that triggers a similar discrepancy between vte and xterm? On my machines running locally we are similar in speed to xterm and much faster when running remotely. However as can be seen with bug 345284, different machines have wildly different behaviour :-( From the xtrace above the Create, Free and SetClip are all due to the drawable changing between each exposes (which can be avoided by inserting a hack into gtk+). Which leaves the 187 vs 38 CompositeGlyphs which I can only hope is due to us splitting in order to avoid long Glyph sequences (as they appeared to hit a slow path in the fglrx driver).
Found one issue where the code was introducing a break in the Glyphs at the end of each line. r1896: 2007-05-23 Chris Wilson <chris@chris-wilson.co.uk> cf Bug 439247 – scrolling vim in full screen is painfully slow and takes up 100% of the cpu * src/vte.c (vte_terminal_draw_rows): Fix up the unwanted break of Glyph runs at the end-of-lines.
Ok, trying with trunk, here you go. xterm is using DejaVu LGC Sans Mono: -rw-rw-r-- 1 behdad behdad 121483397 May 24 13:40 vim-gt.log -rw-rw-r-- 1 behdad behdad 240606134 May 24 13:57 vim-xterm.log [behdad@behdad perf]$ wc -l vim-gt.log vim-xterm.log vim-xterm2.log 441376 vim-gt.log 1334910 vim-xterm.log $ cat vim-xterm.log | grep RENDERRequest | cut -d : -f 6 | cut -d ' ' -f 2 | sort | uniq -c 508 RenderAddGlyphs 122206 RenderCompositeGlyphs16 171713 RenderCompositeGlyphs8 9 RenderCreateCursor 3 RenderCreateGlyphSet 15 RenderCreatePicture 271634 RenderFillRectangles 9 RenderFreePicture 3 RenderQueryPictFormats 3 RenderQueryVersion 752 RenderAddGlyphs 144 RenderChangePicture 35 RenderComposite 217063 RenderCompositeGlyphs16 139912 RenderCompositeGlyphs8 10 RenderCreateCursor 14 RenderCreateGlyphSet 13673 RenderCreatePicture 6872 RenderFillRectangles 11 RenderFreeGlyphSet 13670 RenderFreePicture 1 RenderQueryPictFormats 1 RenderQueryVersion 13470 RenderSetPictureClipRectangles 96 RenderTrapezoids So, it's not clear at all to me, what's going on. The g-t one took 6 minutes under xtrace, the xterm took 10 mins. One thing though, maybe reducing the 20ms timer we have in vte does something interesting here. I'll experiment.
(In reply to comment #4) > Ok, trying with trunk, here you go. xterm is using DejaVu LGC Sans Mono: > > -rw-rw-r-- 1 behdad behdad 121483397 May 24 13:40 vim-gt.log > -rw-rw-r-- 1 behdad behdad 240606134 May 24 13:57 vim-xterm.log > > [behdad@behdad perf]$ wc -l vim-gt.log vim-xterm.log vim-xterm2.log > 441376 vim-gt.log > 1334910 vim-xterm.log > > $ cat vim-xterm.log | grep RENDERRequest | cut -d : -f 6 | cut -d ' ' -f 2 | > sort | uniq -c > 508 RenderAddGlyphs > 122206 RenderCompositeGlyphs16 > 171713 RenderCompositeGlyphs8 > 9 RenderCreateCursor > 3 RenderCreateGlyphSet > 15 RenderCreatePicture > 271634 RenderFillRectangles > 9 RenderFreePicture > 3 RenderQueryPictFormats > 3 RenderQueryVersion > The following set was for gt: > 752 RenderAddGlyphs > 144 RenderChangePicture > 35 RenderComposite > 217063 RenderCompositeGlyphs16 > 139912 RenderCompositeGlyphs8 > 10 RenderCreateCursor > 14 RenderCreateGlyphSet > 13673 RenderCreatePicture > 6872 RenderFillRectangles > 11 RenderFreeGlyphSet > 13670 RenderFreePicture > 1 RenderQueryPictFormats > 1 RenderQueryVersion > 13470 RenderSetPictureClipRectangles > 96 RenderTrapezoids > > So, it's not clear at all to me, what's going on. The g-t one took 6 minutes > under xtrace, the xterm took 10 mins. > > One thing though, maybe reducing the 20ms timer we have in vte does something > interesting here. I'll experiment. >
*** Bug 572827 has been marked as a duplicate of this bug. ***
bug 350015, bug 439247, bug 532816 and bug 572210 all look very much like addressing the same issue.
Still reproducible in git master?