2016-04-21 2:06 GMT+09:00 Christian Ludwig <[email protected]>: > Hello Kazunobu Kuriyama, > > > Thank you for checking. > > > >> if I make then the gtk3vim-Window active > > > > What do you mean by "active"? Raising the window on top of the another > > window, or restarting the vim process that had been stopped then? > > Raising the window on top of the others (=bring to front). The same gvim > process was running (=no restart). > > > > > Apparently, it looks like the gvim stopped and was unable to redraw > itself. > > The point is: gvim didn't try to redraw. gvim was not hanging. If I > enter ":redraw!" then gvim had no problem redrawing all the content. > > > > > And how did you remove a window that had been on the gvim? It appears > not > > by mouse dragging... > > I switch between active windows with "Alt-Tab". No mouse movement or > mouse-action was involded. The steps were > 1. Use gvim (it is active window) > 2. Use Alt-Tab to switch to another (running) application, i.e. other > application has now window in front of gvim. Some parts of the gvim > window are still visible. > 3. Use Alt-Tab to switch back to gvim (i.e. make gvim the "foreground > window"; bring it to frong; I don't know how you call this in English). > The gvim-Window is then brought to front (gvim is top most window). But > gvim only repaint/redraw parts of its area (that was the screenshot). > Escpecially not all of the rectangle that was covered is redrawn. > > gvim does not hang or stop or segfault. gvim just "forgot" the redraw > all the necessary parts. > > > > >> then sometimes huge parts of the gtk3vim window are "empty" > > > > As you know, recent window systems and GUI toolkits allow us to use > > transparent/translucent background. To make it possible, they must know > > not only the content of top windows but also part of the screen covered > > with them. > > I'm not using transparency (alpha-channel). All parts in my gui are opaque. > > > > > So I'm wondering how that can be possible with a modern window system > and a > > GUI toolkit. > > > > The picture looks like what was seen in the era when > > transparent/translucent background was impossible. that is, both window > > systems and GUI toolkits didn't care about what had been drawn under > > windows because, due to opaque background, keeping it somewhere in memory > > was of use. > > I don't think it has something to do with tranparency or something. Or > do you mean the background color of gvim. Sorry I used a colorscheme > (solarized) so the background of gvim had a differnt color than white or > black. > > No, no. It doesn't matter whether or not you actually use translucent background.
Even if you don't use translucent background, the system and the toolkit has to get ready for composing the content of the topmost window and that of every window below it by drawing every content of the windows from back to front in order to "synthesize" that translucency. To do that, there's no choice for the system and the toolkit to skip the drawing of the covered part of a window. That is, no chance to make an empty square out of that. So, what the picture shows is...it looks to me...something impossible by design. Probably, the window manager or the X11 server can't send expose events to gvim for some reason, though I'm not sure of that. What the patch is doing is that, instead of unconditionally repainting the background of the whole window, only repainting that of lines which is to be redrawn. So it is very difficult for me to conclude that the patch causes the issue you're reporting. > > >> Sometimes there is a huge repainting problem > > > > Do you have any clue or guess when that happens? > > In my case: nearly every time when gvim has to redraw part of its window > after switching back with Alt-Tab. > > Instead of trying to describe this with my bad English, I can make a > movie if this helps. > When I need it, I'll ask you so. As for English, it's clear that I'm not in a position to say something :) > > > > > > >> I've tested your patch. > > > > So...what is the result? Does the patch fix the "original" issue? > > The original issue was about the blinking speed of the cursor ... please > don't ask me how regular/irregular the blinking is ... > I tested if there are new/old problems using the patch. > I see... Anyway, apart from it being a gtk3vim bug or not, you reported a real issue and I appreciate it. But I think we should have discussed it in another thread... So I want to go back to the original issue now. Is there anyone who can check if the patch fixes the cursor blinking rate issue in conjunction with async I/O? > > > Bye > C. Ludwig > Thank you for the clarification and the explanation. Kazunobu > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
