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 <[email protected]>:

> On 19/04/16 11:42, Kazunobu Kuriyama wrote:
> > 2016-04-19 15:49 GMT+09:00 Bram Moolenaar <[email protected]>:
> >
> >>
> >> 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 [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.

Raspunde prin e-mail lui