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. > >> 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. > > >> 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. Bye C. Ludwig -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
