GVim flickers during page down/up scrolling - fonts renderer issue?
Mikey
I use GVim ver. 7.3.154 with GTK2 GUI on Slackware 13.37. During page
down/up scrolling with Ctrl-F/B keys, screen flickers. It is
especially well seen when GVim is maximized and working with large
files (for example /var/log/messages) where text fills entire screen
(not only from top to bottom, but also from left to right). Launching
GVim with '-u NONE - U NONE' changes nothing. For additional
comparison I opened the same file with Emacs 23.3.1 and rendering was
very smooth. Of course both editors use exactly the same font. Is
there any chance that GVim will use equally efficient rendering
technique as Emacs? I'm a visually impaired person and this problem
has a great meaning for me. As far as I know Emacs uses libXft to
render fonts. Maybe lack of libXft support in GVim is the core of the
issue?
Regards, Mike.
Tony Mechelynck
Try using a more recent version. Vim 7.3.154 dates back from 2011-04-02;
the current patchlevel is 7.3.409. In the 255 fixes between your version
and the current one, some flicker problems have been fixed but I'm not
sure they are exactly what you're seeing. IMHO there's not much risk in
trying anyway.
See:
http://ftp.vim.org/pub/vim/patches/7.3/README
a one-line description of every patch to Vim 7.3
and if you want to compile your own Vim (not very hard)
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
Best regards,
Tony.
--
press CTRL-ALT-DEL for more information
Christian Brabandt
I don't remember, that any rendering issues have been fixed since the
release of 7.3 Try if scrolling using <C-E>/<C-U> works better, e.g.
fu! Scroll(up)
return ":\<C-U>exe \":norm! ". v:count1*winheight(0) . (a:up ?
'\<C-U>' : '\<C-E>')."\"\n"
endfu
nunmap <C-F>
nunmap <C-D>
nnoremap <expr> <C-F> Scroll(0)
nnoremap <expr> <C-D> Scroll(1)
regards,
Christian
Mikey
On Jan 22, 11:39 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
Mikey
On Jan 23, 10:22 am, "Christian Brabandt" <cbli...@256bit.org> wrote:
> I don't remember, that any rendering issues have been fixed since the
> release of 7.3 Try if scrolling using <C-E>/<C-U> works better, e.g.
>
> fu! Scroll(up)
> return ":\<C-U>exe \":norm! ". v:count1*winheight(0) . (a:up ?
> '\<C-U>' : '\<C-E>')."\"\n"
> endfu
>
> nunmap <C-F>
> nunmap <C-D>
> nnoremap <expr> <C-F> Scroll(0)
> nnoremap <expr> <C-D> Scroll(1)
>
> regards,
> Christian
Mikey
problem. I've described one method in my first post but please let me
try with another example:
gvim -u NONE -U NONE
:set laststatus=1
:set ruler
:h eval
:only
Now look at right bottom of your screen. If I'm right, you will see
flickering line, column and percentage indicators during page down/up
scrolling. I can see exactly the same thing, but on entire screen.
And one more hint: Windows OS version of GVim is not affected by this
flaw. I really don't think it's a problem with GVim iself but with
rendering libraries it uses on Linux. Here I've found post related to
my problem:
http://www.linuxquestions.org/questions/linux-software-2/how-to-speed-up-gvim-by-factor-of-3-and-remain-sane-647560/
sc
i wonder if you are experiencing the scrolling jitters caused by
line wrap -- do the modules you scroll have long lines, and do
you have wrap turned on? if so, just to see if that's what's
causing what you see, try
:set nowrap
and tell us if you still see the jitters
Christian Brabandt
Try setting the window option to a smaller value.
regards,
Christian
--
Mikey
On Jan 23, 3:21 pm, sc <tooth...@swbell.net> wrote:
> i wonder if you are experiencing the scrolling jitters caused by
> line wrap -- do the modules you scroll have long lines, and do
> you have wrap turned on? if so, just to see if that's what's
> causing what you see, try
>
> :set nowrap
>
> and tell us if you still see the jitters
Mikey
On Jan 23, 6:24 pm, Christian Brabandt <cbli...@256bit.org> wrote:
> Try setting the window option to a smaller value.
does :(
Dominique Pellé
I suspect that you need to install the hardware driver for
your graphical card. I experienced gvim (gtk2) screen refresh
being very slow on my laptop to the point of being unusable. I
could see the lines being refreshed one by one. It happened
after my nvidia driver somehow got disabled. Reinstalling the
latest nvidia driver made gvim fast again In Ubuntu-10.04, it
was only a matter of doing choosing from main menu:
System->Administration->Hardware drivers
Regards
-- Dominique
Mikey
ATI drivers as well as with open source NVidia drivers - GVim
flickered everywhere.
After all, I've settled for GVim with Motif GUI instead of GTK2. It
isn't completely flicker-free but much, much better than GTK2 version.
Mikey
Accidentally I've discovered some new facts about described problem.
In contrast to my previous posts now I dare to claim that the source
of bug is in the Vim itself. Steps to reproduce:
1) $ gvim -u NONE -U NONE
2) maximize GVim window.
3) switch to Insert mode and write some text with <EOL> at the end,
eg:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc ornare
nisl eget quam tincidunt ullamcorper.<CR>
4) copy the line you've just entered and paste it 10 000 times.
OK, now you have single window with 10 001 lines, ~100 characters
each. Start page up/down scrolling with Ctrl-f/b. You should see
flicker. If you don't - stop reading and treat this post as non-
existent - it seems that bug is unreproducible and local to only my
machines. But if you do, let the experiment continue:
:vsplit
:set nowrap
Play with Ctrl-f/b once again. You should see flicker with Ctrl-f but
Ctrl-b should be flicker-free! So, it's possible to render without
flicker. I think it's proof that there is a bug with screen redrawing
code inside Vim. Please confirm my observations or I'll be heard of no
more.
John Little
> Hello again.
>
> Accidentally I've discovered some new facts about described problem.
> In contrast to my previous posts now I dare to claim that the source
Yes, I get "it" too, but it's more of a flash than a flicker. Going
forward a screen Vim seems to clear the screen, then redraw it, but
gets interrupted and pauses a third of the way through, and at two
thirds. And yes, after a :vsplit page up doesn't flash.
Interestingly, the behaviour is identical with vim in gnome-terminal,
konsole, and xterm.
Regards, John
Christian Brabandt
I am not sure why, but this patch seems to fix it. This potentially
makes redrawing much slower, though.
diff --git a/src/move.c b/src/move.c
--- a/src/move.c
+++ b/src/move.c
@@ -2533,7 +2533,7 @@
}
}
- redraw_later(VALID);
+ redraw_later(NOT_VALID);
return retval;
}
regards,
Christian
--
Mikey
On Feb 4, 2:33 pm, Christian Brabandt <cbli...@256bit.org> wrote:
> I am not sure why, but this patch seems to fix it. This potentially
> makes redrawing much slower, though.
indeed faster.
But there is a problem with your patch. After John Little had
confirmed my observations, I investigated a little and found that this
'flashing' is more general bug i.e. not only with ctrl-f/b but also
with ctrl-d/u, gg, G, :set scrolljump=-25 or even :set scrolljump=1
and maybe more. I dont't have the foggiest idea about Vim's internals
but I suspect it should be fixed on some higher level than your
attempt.
Marko Mahnič
> I dont't have the foggiest idea about Vim's internals
> but I suspect it should be fixed on some higher level than your
> attempt.
an application: the application draws text into an off-screen buffer,
then it displays the buffer. I'm not sure, but I think that Vim
doesn't use double buffering. Instead it (I think) tries to modify
only the parts of the screen that have actually changed. When
scrolling (eg. when you move down line by line) it may also copy the
part of the screen that will be visible after the scroll to a new
location.
When you move by page (or pressing ctrl-L), the whole screen needs to
be updated. It is first cleared and then redrawn, and both changes are
immediately visible. On slow graphic cards and large Vim windows the
flicker appears stronger because it takes more time to redraw the
screen. The flicker is usually stronger in the bottom lines.
Hope this helps,
Marko
Christian Brabandt
I think, for each command a similar patch would need to be applied. But
I don't think this is reasonable. What Marko said, sounds reasonable,
but I don't know, what a good solution would be.
Mit freundlichen Gr��en
Christian
--
MacDonald, Stuart
From: On Behalf Of Christian Brabandt
> On Fr, 03 Feb 2012, John Little wrote:
>
> > On Feb 4, 10:17 am, Mikey <smieciar...@gmail.com> wrote:
> > > Hello again.
> > >
> > > Accidentally I've discovered some new facts about described problem.
> > > In contrast to my previous posts now I dare to claim that the source
> > > of bug is in the Vim itself. Steps to reproduce: ...
> >
> > Yes, I get "it" too, but it's more of a flash than a flicker. Going
> > forward a screen Vim seems to clear the screen, then redraw it, but
> > gets interrupted and pauses a third of the way through, and at two
> > thirds. And yes, after a :vsplit page up doesn't flash.
I see a flicker, but it's expected, see below.
> I am not sure why, but this patch seems to fix it. This potentially
> makes redrawing much slower, though.
>
> diff --git a/src/move.c b/src/move.c
> --- a/src/move.c
> +++ b/src/move.c
> @@ -2533,7 +2533,7 @@
> }
> }
>
> - redraw_later(VALID);
> + redraw_later(NOT_VALID);
> return retval;
> }
This is without looking at the code, so ICBW...
This is a well-known although possibly fallen-into-disuse graphics
optimization: if you're partway through drawing the screen and you get
a command that will cause a redraw, abandon the current drawing and
start the next drawing.
The patch probably turns the optimization off, which should make the
scrolling slower because each view on the data is fully drawn before
the next navigation command occurs.
The fact that there is no flicker when scrolling up is an artifact of
the top-to-bottom drawing process.
I'm not sure this is something that needs to be fixed. I pasted the
10,001 lines to notepad and see the same thing when scrolling.
Hm. Although in notepad there is flicker in both directions, so I'm
wondering if the lack of flicker when scrolling up in gvim is in fact
a bug: the optimization is not applied correctly?
...Stu
Peter Robinson
1. In MacOS, GVim (or rather MVim) works perfectly, no flickering whatsoever.
2. In Linux (on the same machine), the flickering in GVim is very noticeable when using fast scrolling, for the exact same file that works smoothly using MVim in MacOs. If I open the same file in a console using vim, there is no flickering.
I also compiled the latest GVim with motif instead of GTK2 but the problem persists, which tells me that the issue must be in the way the redrawing of the screen is handled (that works fine with Quartz (MacOS) but has performance issues with X).
PS: I've also tried to recompile with the line "redraw_later(NOT_VALID);" in move.c as suggested earlier, but this didn't have any noticeable effect.
Peter
Dominique Pellé
> I'm having the same problem with the most recent GVim under certain scenarios:
> 1. In MacOS, GVim (or rather MVim) works perfectly, no flickering whatsoever.
> 2. In Linux (on the same machine), the flickering in GVim is very noticeable when using fast scrolling, for the exact same file that works smoothly using MVim in MacOs. If I open the same file in a console using vim, there is no flickering.
> I also compiled the latest GVim with motif instead of GTK2 but the problem persists, which tells me that the issue must be in the way the redrawing of the screen is handled (that works fine with Quartz (MacOS) but has performance issues with X).
>
> PS: I've also tried to recompile with the line "redraw_later(NOT_VALID);" in move.c as suggested earlier, but this didn't have any noticeable effect.
and it turned out that I did not install a driver and did
not have 3D hardware acceleration. After installing the
driver on Linux, Vim no longer flickered. I don't
know if it's the same problem, but what's the output
of running "glxinfo | grep rendering"? It should say:
$ glxinfo | grep rendering
direct rendering: Yes
Regards
PS: please bottom post in the vim mailing list.