Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File->Open does not update window content correctly - Appeared first in v7-3-638 #91

Closed
GoogleCodeExporter opened this issue Aug 18, 2015 · 14 comments

Comments

@GoogleCodeExporter
Copy link


Problem is not present in tag v7-3-637. Problem appeared first in tag v7-3-638.

What steps will reproduce the problem?
Using gvim:
1. Go to v7-3-638 vim source directory
2. File->Open and select Filelist
3. Content shows correctly
4. File->Open and select README.txt
5. Contents are not updated, section of Filelist still shows
6. Move mouse wheel or cursor, contents are now updated correctly

What is the expected output? What do you see instead?
Exepcted output is content of newly opened file. I see part of old file until 
screen refreshes by moving cursor.

What version of the product are you using? On what operating system?
Linux Mint 13 with MATE 1.2 or 1.4
gvim compiled from source with: ./configure --enable-gui=gtk2 
--enable-rubyinterp=yes --with-features=huge
Kernel:  3.2.0-32-generic #51-Ubuntu SMP

Please provide any additional information below.

Problem is not present in tag v7-3-637. Problem appeared first in tag v7-3-638.

Original issue reported on code.google.com by yerv...@gmail.com on 3 Nov 2012 at 1:33

@GoogleCodeExporter
Copy link
Author

Is this still reproducable?

Original comment by chrisbr...@googlemail.com on 30 Sep 2014 at 6:38

@GoogleCodeExporter
Copy link
Author

Still reproducible with Linux Mint (LMDE with MATE) stock package (7.4, 
--version saying includes patches 1-52) or my own build (7.4 from official dl 
site, same configure option).

Additional comments:
1. More likely to occur when navigating with Ctrl-F/Ctrl-B, leaving at least 
half of the screen blank.
2. Only gvim is affected. vim is fine.

Original comment by fancymo...@fancymouse.net on 23 Nov 2014 at 2:15

@GoogleCodeExporter
Copy link
Author

I can reproduce the issue. Unfortunately, I do not know, why patch 7.3.638 
should cause the issue. It looks to me, like the gtk drawing libraries are not 
updating the window correctly, because if I see this correctly, Vim requests 
redrawing of the complete buffer content. I do not know gtk good enough to 
propose a fix though.

Original comment by chrisbr...@googlemail.com on 24 Nov 2014 at 9:58

@GoogleCodeExporter
Copy link
Author

You might want to report that bug also to the Mate developers, because it seems 
to be Mate specific (or does it happen with other desktop environments?).

Nevertheless, Here is a simple patch, that forces a redraw in the gtk gui, that 
seems to work around the problem. Nevertheless, it would be good, if a 
developer with a more found GTK background could have a look at that issue (and 
my patch).

Original comment by chrisbr...@googlemail.com on 25 Nov 2014 at 6:31

Attachments:

@GoogleCodeExporter
Copy link
Author

Thanks for the patch. Although with your patch as is, Ctrl-F/B still breaks. 
But after I comment out "if (type >= NOT_VALID)", it now looks good to me.

Original comment by fancymo...@fancymouse.net on 5 Dec 2014 at 12:04

@GoogleCodeExporter
Copy link
Author

Original comment by chrisbr...@googlemail.com on 9 Jan 2015 at 12:18

  • Added labels: patch

@GoogleCodeExporter
Copy link
Author

May not be a Mint specific problem... just got a chance to have a try from 
Debian Testing (jessie rc1) and it's even worse. The patch still works.

Original comment by fancymo...@fancymouse.net on 10 Mar 2015 at 10:23

@GoogleCodeExporter
Copy link
Author

The problem with this approach is, it will make Vim a whole lot slower, since 
what it really does it always force a complete redraw. That is most certainly 
not what is wanted. 

Original comment by chrisbr...@googlemail.com on 11 Mar 2015 at 6:17

@GoogleCodeExporter
Copy link
Author

I cannot reproduce the problem.  It smells like a GTK library problem.

The patch will redraw too often, causing flicker.
Patch 7.3.638 merely removed an unnecessary redraw, which likely uncovered an 
existing problem.

Original comment by brammool...@gmail.com on 24 Mar 2015 at 3:17

@GoogleCodeExporter
Copy link
Author

Same Problem here: Ubuntu 14.04 in a VMware Workstation environment. If I start 
vim with athena ("vim.athena -g") I cannot reproduce it. Two other Ubuntu 14.04 
installations under Virtualbox do not show the problem.

The current workaround for me is to start gvim with "--sync" option.

Original comment by gugelge...@gmail.com on 30 Jun 2015 at 12:02

@wsdjeg
Copy link

wsdjeg commented Sep 9, 2015

is there any differeces between vim and gvim in ubuntu system,i have navel used gvim.

@benbaez
Copy link

benbaez commented Sep 20, 2016

I have the same issue as GoogleCodeExporter using VMware Workstation 12.5 and Ubuntu 16.04 patched to latest. Existed in Ubuntu 14 and Workstation 12 as well. Host is a HP Z620. This only occurs on this host all 3 of Ubuntu I am running. Haven't noticed the issue on CentOS. Using --sync option is a workaround.

@nuko8
Copy link

nuko8 commented Sep 20, 2016

Roughly speaking, X clients cannot update their window content until a certain event from the X11 server arrives at their event queue and then drives the event loop to invoke the callback function for update.

As for the GTK2 GUI, the callback function for update is quite passive. It is associated with update events at initialization and never dissociated from them until the process terminates. In addition, there’s no code at all in the implementation to block update events at runtime.

Moreover, as indicated in the top post:

  1. Move mouse wheel or cursor, contents are now updated correctly

and in @chrisbra's gtk2_force_redraw.diff, the callback function works as expected once it gets an update event or another event which induces update.

In short, just like any other X clients, the GUI is made not to exercise its veto over any update requests.

Accordingly, it is highly likely that either of the windowing system under a certain environment or the GTK library (or some interaction between them) prevents update events from being delivered to the GUI for the case in question.

If this is the case, there’s nothing left for the GUI to do with.

@chrisbra
Copy link
Member

i am closing this, as this is no gvim issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants