Sorry, typo. > "keeping it somewhere in memory was of use."
should read "keeping it somewhere in memory was of *no* use." 2016-04-21 0:38 GMT+09:00 Kazunobu Kuriyama <kazunobu.kuriy...@gmail.com>: > 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? > > Apparently, it looks like the gvim stopped and was unable to redraw itself. > > And how did you remove a window that had been on the gvim? It appears not > by mouse dragging... > > > 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. > > 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. > > > Sometimes there is a huge repainting problem > > Do you have any clue or guess when that happens? > > > I've tested your patch. > > So...what is the result? Does the patch fix the "original" issue? > > Best regards, > Kazunobu Kuriyama > > > 2016-04-20 23:27 GMT+09:00 Christian Ludwig <c...@exomail.to>: > >> On 19/04/16 11:42, Kazunobu Kuriyama wrote: >> > 2016-04-19 15:49 GMT+09:00 Bram Moolenaar <b...@moolenaar.net>: >> > >> >> >> >> The GUI cursor blinking restarts the timer every time. That's a >> >> separate problem though. >> >> >> > >> > Year, that's true. In addition to that, I think the irregularity of the >> > cursor blinking pace is also caused by the whole window re-paintings >> which >> > are triggered by the async I/O buffer updates. >> > >> > The attached patch is for the GTK3 GUI and I hope it fixes the issue. >> > >> > But I have one thing to worry about. Since the patch changes the draw >> > event code, it might be possible to introduce a regression against >> Linux. >> > >> > So, before formally submitting the patch to Bram, I'd like to make sure >> if >> > it works well on Linux. >> > >> > I'd appreciate it if someone would check that. >> >> I've tested your patch. Sometimes there is a huge repainting problem: >> >> If my gtk3vim-Window is partially covered by some other window and if I >> make then the gtk3vim-Window active, then sometimes huge parts of the >> gtk3vim window are "empty"; only the current row/line and the first >> columns are drawn. >> I've attached a screen shot. [From the missing parts, you can see/guess >> exactly where the overlapping window was.] >> >> 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. >> > > -- -- 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.
