Re: [vim/vim] Improve color emoji (#2401)

2018-02-23 Fir de Conversatie Blay263
On Saturday, December 9, 2017 at 12:40:29 PM UTC-5, Blay263 wrote:
> On Thursday, December 7, 2017 at 8:34:17 AM UTC-5, Ken Takata wrote:
> > Hi,
> > 
> > 2017/12/7 Thu 19:56:43 UTC+9 David Kotchan wrote:
> > > On Saturday, December 2, 2017 at 7:03:33 AM UTC-8, K.Takata wrote:
> > > 
> > > > Hi,
> > > > 
> > > > This pull-request is a supplemental patch for #2375 (v8.0.1343).
> > > > 
> > > > This introduces some performance improvements and fixes a bug:
> > > > 
> > > > Improve performance when underlines, strikethroughs or undercurls are 
> > > > used.
> > > > 
> > > > v8.0.1343 uses GDI to draw these lines, however, switching between 
> > > > DirectX and GDI causes terrible slowdown.
> > > > 
> > > > This PR uses Direct2D APIs to draw the lines.
> > > > 
> > > > Improve performance when GDI fallback occurs by using a raster font.
> > > > 
> > > > This PR draws texts on top of a Direct2D surface even if a raster font 
> > > > is selected.
> > > > 
> > > > Add 'scrlines' suboption to the 'rop' option for performance tuning.
> > > > 
> > > > On some environments, redrawing is faster than scrolling. (On my 
> > > > environment, redrawing is about 2x faster.)
> > > > 
> > > > Users can optimize scrolling behavior by using this suboption.
> > > > 
> > > > Fix a bug that the 'mFallbackDC' variable was not properly updated.
> > > > ...
> > > 
> > > I very much appreciate the work that went into the rendering 
> > > improvements. This is great stuff.
> > > 
> > > But after compiling Vim 8 up to patch 1376 (Huge version with GUI; Visual 
> > > Studio 2017), I am finding that rendering is quite slow on some systems.
> > > 
> > > On my machine at work, which is: Win10 Enterprise, OS build 15063.726, 
> > > 64-bit, with an AMD Radeon R9 M370X video card, the rendering is much 
> > > slower than (say) Vim 8 patched to 1366. The screen scrolling cannot keep 
> > > up with ordinary j/k {up/down} keys held down, for example. Window 
> > > refreshes are noticeably slow. There are various flickers here and there 
> > > as the cursor redraws text items on screen during scrolling. These 
> > > flickers are absent (or are so fast, as to be visually absent) on Vim 8 
> > > patch 1366 for example.
> > 
> > Oh, that is totally unexpected.
> > Does the behavior depends on the text you are editing?  The patch 8.0.1369
> > should have improved the performance when showing underlines, undercurls, 
> > etc.
> > Does the scroll speed change when the following setting is used?
> > 
> > set rop=type:directx,scrlines:1
> > 
> > 
> > > On the other hand, on my machine at home, which is: Win10 Pro, OS build 
> > > 15063.726, 64-bit, with an NVidia GeForce GTX 745 video card, there are 
> > > no problems at all(!) Vim 8 patch 1376 is just as fast as patch 1366, and 
> > > the new colored Emoji show up fine.
> > > 
> > > Both systems use the same monospace font (Roboto Mono) and have the same 
> > > _vimrc, _gvimrc and plugins. No Vim functionality is impaired, just the 
> > > drawing speed.
> > > 
> > > Does anyone has any ideas why rendering performance would be so different 
> > > on what would seem to be two essentially identical operating systems and 
> > > (I would have thought) more or less equally capable video cards?
> > 
> > 
> > Regards,
> > Ken Takata
> 
> After this update, I am having several issues :
> -y and g are cutoff
> -artifacts are left behind (see after pic below the status line)
> -status line is miss aligned

The alignment is better but it is still slightly out of position at the top

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2018-01-18 Fir de Conversatie Ken Takata
Hi all,

2017/12/23 Sat 1:26:22 UTC+9 David Kotchan wrote:
> On Thursday, December 21, 2017 at 2:52:47 PM UTC-8, Ken Takata wrote:
> > Ah, okay.  One of my desktop PC at work also becomes slow after 8.0.1343,
> > when executing such as `:ver`, `:dig`, `:hi` and some other commands. 
> > (However,
> > scrolling a text by keep pressing Ctrl-F or Ctrl-B becomes faster on that
> > machine.)
> >
> > I found that gui_mch_flush() was very slow on that machine.  It took more 
> > than
> > 3 ms on it, however it took about 1 ms on another note PC.  So, the desktop 
> > PC
> > is 3x slower.  Moreover, when the window size of Vim becomes larger, it 
> > becomes
> > slower.  I think the most important thing for improving the performance is
> > reducing the call of gui_mch_flush().
> > 
> > I have updated the 'optimize-directx' branch in the 'vim-jp/vim' repository.
> > It becomes slightly faster than the latest patch (8.0.1418), but it is still
> > slower than 8.0.1342 on the desktop PC.  (The branch is much faster than 
> > 1342
> > on other PCs.)  I think it is very hard to make it faster than this.
> > It might be an issue of the display driver.
> 
> Thank you Ken. (It's fortunate you found a PC system at work to reproduce the 
> issue, that was lucky. Thanks for investigating.)
> 
> I am pleased to report, that your "optimize-directx" branch in 'vim-jp/vim' 
> is pretty good on my Win10 Enterprise machine. Nice! You are right, it is not 
> as fast as 1342. But it is reasonably OK now and I can use it. And as you 
> say, Ctrl+F/Ctrl+B and Ctrl+U/Ctrl+D are very fast, which is good.
> 
> Thank you for your great work on tracking this down! Interesting to see your 
> remark about gui_mch_flush(), it is curious how that becomes slow. I guess 
> you are right, it may be a display driver issue.
> 
> Thanks again for your time and expertise! Great work.

I created a PR for this:
https://github.com/vim/vim/pull/2560

Regards,
Ken Takata

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-22 Fir de Conversatie David Kotchan
On Thursday, December 21, 2017 at 2:52:47 PM UTC-8, Ken Takata wrote:
> Ah, okay.  One of my desktop PC at work also becomes slow after 8.0.1343,
> when executing such as `:ver`, `:dig`, `:hi` and some other commands. 
> (However,
> scrolling a text by keep pressing Ctrl-F or Ctrl-B becomes faster on that
> machine.)
>
> I found that gui_mch_flush() was very slow on that machine.  It took more than
> 3 ms on it, however it took about 1 ms on another note PC.  So, the desktop PC
> is 3x slower.  Moreover, when the window size of Vim becomes larger, it 
> becomes
> slower.  I think the most important thing for improving the performance is
> reducing the call of gui_mch_flush().
> 
> I have updated the 'optimize-directx' branch in the 'vim-jp/vim' repository.
> It becomes slightly faster than the latest patch (8.0.1418), but it is still
> slower than 8.0.1342 on the desktop PC.  (The branch is much faster than 1342
> on other PCs.)  I think it is very hard to make it faster than this.
> It might be an issue of the display driver.

Thank you Ken. (It's fortunate you found a PC system at work to reproduce the 
issue, that was lucky. Thanks for investigating.)

I am pleased to report, that your "optimize-directx" branch in 'vim-jp/vim' is 
pretty good on my Win10 Enterprise machine. Nice! You are right, it is not as 
fast as 1342. But it is reasonably OK now and I can use it. And as you say, 
Ctrl+F/Ctrl+B and Ctrl+U/Ctrl+D are very fast, which is good.

Thank you for your great work on tracking this down! Interesting to see your 
remark about gui_mch_flush(), it is curious how that becomes slow. I guess you 
are right, it may be a display driver issue.

Thanks again for your time and expertise! Great work.

--David

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-21 Fir de Conversatie Ken Takata
Hi,

2017/12/20 Wed 3:24:50 UTC+9 David Kotchan wrote:
> On Thursday, December 14, 2017 at 11:51:45 PM UTC-8, Ken Takata wrote:
> 
> > 
> > Maybe we should check step by step.
> > 
> > At first, I'd like to confirm again that the patch 1369 is actually the
> > cause of the slowdown.
> > Could you checkout 'v8.0.1368' and check if the slowdown doesn't occur?
> > 
> 
> Ken, you are right, and once again I have been stupid/sloppy. My Win10 
> Enterprise Vim was actually much older than 1366: it was patch 1206. I am not 
> sure how I got "1366" stuck in my head (probably confusion with the Vim 
> version I use at home on Win10 Professional).
> 
> OK. So now, I have done a detailed bisect of exactly which patch started 
> causing the issue. It is: patch 1343 "MS-Windows: does not show colored 
> emojis". Patch 1342 is quite fast, as usual. Patch 1343 is where Vim becomes 
> slow.
> 
> Sorry for the misleading information from earlier :-( Hopefully, the firm 
> knowledge that the problem started occurring at patch 1343 (commit 
> d7ccc4d81dbcfa3ac0352bacea6e294fc9e33fda) will shed some light on the matter.

Ah, okay.  One of my desktop PC at work also becomes slow after 8.0.1343,
when executing such as `:ver`, `:dig`, `:hi` and some other commands. (However,
scrolling a text by keep pressing Ctrl-F or Ctrl-B becomes faster on that
machine.)
I found that gui_mch_flush() was very slow on that machine.  It took more than
3 ms on it, however it took about 1 ms on another note PC.  So, the desktop PC
is 3x slower.  Moreover, when the window size of Vim becomes larger, it becomes
slower.  I think the most important thing for improving the performance is
reducing the call of gui_mch_flush().

I have updated the 'optimize-directx' branch in the 'vim-jp/vim' repository.
It becomes slightly faster than the latest patch (8.0.1418), but it is still
slower than 8.0.1342 on the desktop PC.  (The branch is much faster than 1342
on other PCs.)  I think it is very hard to make it faster than this.
It might be an issue of the display driver.

Regards,
Ken Takata

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-19 Fir de Conversatie David Kotchan
On Thursday, December 14, 2017 at 11:51:45 PM UTC-8, Ken Takata wrote:

> 
> Maybe we should check step by step.
> 
> At first, I'd like to confirm again that the patch 1369 is actually the
> cause of the slowdown.
> Could you checkout 'v8.0.1368' and check if the slowdown doesn't occur?
> 

Ken, you are right, and once again I have been stupid/sloppy. My Win10 
Enterprise Vim was actually much older than 1366: it was patch 1206. I am not 
sure how I got "1366" stuck in my head (probably confusion with the Vim version 
I use at home on Win10 Professional).

OK. So now, I have done a detailed bisect of exactly which patch started 
causing the issue. It is: patch 1343 "MS-Windows: does not show colored 
emojis". Patch 1342 is quite fast, as usual. Patch 1343 is where Vim becomes 
slow.

Sorry for the misleading information from earlier :-( Hopefully, the firm 
knowledge that the problem started occurring at patch 1343 (commit 
d7ccc4d81dbcfa3ac0352bacea6e294fc9e33fda) will shed some light on the matter.

Thanks!
--David 

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-14 Fir de Conversatie Ken Takata
Hi David,

2017/12/15 Fri 3:20:16 UTC+9 David Kotchan wrote:
> On Wednesday, December 13, 2017 at 7:27:59 PM UTC-8, David Kotchan wrote:
> 
> > OK I have re-pulled, and am now on the "optimize-directx" branch, which has 
> > latest commit 9af94dbea8389a5e31a946f53d9d7a11561d1456, one commit after 
> > the 0e7d0764 commit you mention above. I will try this branch (at 9af94dbe).
> [snip]
> > ...Yes, I will also try gdi-cursor branch.  At time of my pull, latest 
> > commit is 192bd7e9e871b5aacb4c1142fe505aaf5bb72dc6. 
> > 
> [snip]
> > Well, I will compile these and report back.  Again, thank you for your time 
> > and effort on this problem!
> 
> Hi Ken
> 
> I am sorry to report, neither the "optimize-directx" (also with scrlines:1) 
> nor the "gdi-cursor" (with gdicursor:1) has helped the problem on my Win10 
> Enterprise system :-/

Oh, that's too bad.


> I have posted a video showing the speed difference (demo), if you are 
> interested. 
> https://onedrive.live.com/?id=6870FB040B1C655B%21700&cid=6870FB040B1C655B
> The first Vim is patch 1366; the second Vim is "gdi-cursor".
> 
> Anyways, I will continue to investigate and perhaps try other compile options.

Maybe we should check step by step.

At first, I'd like to confirm again that the patch 1369 is actually the
cause of the slowdown.
Could you checkout 'v8.0.1368' and check if the slowdown doesn't occur?

Regards,
Ken Takata

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-14 Fir de Conversatie David Kotchan
On Wednesday, December 13, 2017 at 7:27:59 PM UTC-8, David Kotchan wrote:

> OK I have re-pulled, and am now on the "optimize-directx" branch, which has 
> latest commit 9af94dbea8389a5e31a946f53d9d7a11561d1456, one commit after the 
> 0e7d0764 commit you mention above. I will try this branch (at 9af94dbe).
[snip]
> ...Yes, I will also try gdi-cursor branch.  At time of my pull, latest commit 
> is 192bd7e9e871b5aacb4c1142fe505aaf5bb72dc6. 
> 
[snip]
> Well, I will compile these and report back.  Again, thank you for your time 
> and effort on this problem!

Hi Ken

I am sorry to report, neither the "optimize-directx" (also with scrlines:1) nor 
the "gdi-cursor" (with gdicursor:1) has helped the problem on my Win10 
Enterprise system :-/

I have posted a video showing the speed difference (demo), if you are 
interested. 
https://onedrive.live.com/?id=6870FB040B1C655B%21700&cid=6870FB040B1C655B
The first Vim is patch 1366; the second Vim is "gdi-cursor".

Anyways, I will continue to investigate and perhaps try other compile options.

Thank you for your time.
--David

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-13 Fir de Conversatie David Kotchan
On Wednesday, December 13, 2017 at 5:10:04 AM UTC-8, Ken Takata wrote:

> > Hmm, did you use the commit 0e7d0764cc24d7563a9eb8c97f3020274a52d09c on
> > the optimize-directx branch?

Oh, you are right: I was rather stupid, I did not switch to the correct branch. 
That was dumb :-|

OK I have re-pulled, and am now on the "optimize-directx" branch, which has 
latest commit 9af94dbea8389a5e31a946f53d9d7a11561d1456, one commit after the 
0e7d0764 commit you mention above. I will try this branch (at 9af94dbe).

> I created an experimental branch 'gdi-cursor' in the vim-jp/vim repository.
> This adds 'gdicursor' suboption to the 'rop' option.
> 
> If you do `:set rop=type:directx,gdicursor:1`, the old drawing method (which
> was used before 8.0.1369) will be used.
> 
> Could you try this and check if the speed is same as before 8.0.1369?

Yes, I will also try this branch.  At time of my pull, latest commit is 
192bd7e9e871b5aacb4c1142fe505aaf5bb72dc6. 

I also see branch "fix-directx-issues", latest commit 
ee46e9a9c3a91346da3f9a7ffafec00b9422c654.  But I guess that one is for other 
issues, as I see from your other vim-dev posting today (2017-12-13).  OK.

Well, I will compile these and report back.  Again, thank you for your time and 
effort on this problem!

-- David

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-13 Fir de Conversatie Ken Takata
Hi David,

2017/12/12 Tue 23:46:20 UTC+9 Ken Takata wrote:
> Hi,
> 
> 2017/12/12 Tue 13:44:19 UTC+9 David Kotchan wrote:
> > On Monday, December 11, 2017 at 7:06:37 AM UTC-8, Ken Takata wrote:
> > 
> > > I'm also aware the cursor behavior.
> > > I have updated the "optimize-directx" branch in the vim-jp/vim repository.
> > > gui_mch_flush() was called unnecessarily several times, and it caused the
> > > behavior.
> > > I think it is now fixed, but need more tests.
> > 
> > Hi Ken
> > 
> > Thanks for your work! However, I find that pulling code from the latest 
> > branch (https://github.com/vim-jp/) does not help my problem. I tried 
> > compiling it (under VS2017) with several different options:
> 
> Hmm, did you use the commit 0e7d0764cc24d7563a9eb8c97f3020274a52d09c on
> the optimize-directx branch?
> I still have no idea why it becomes slow on your environment.
> 
> Maybe we need to measure where the slow part is.
> Or do we need to add an option to back to the old behavior?

I created an experimental branch 'gdi-cursor' in the vim-jp/vim repository.
This adds 'gdicursor' suboption to the 'rop' option.

If you do `:set rop=type:directx,gdicursor:1`, the old drawing method (which
was used before 8.0.1369) will be used.

Could you try this and check if the speed is same as before 8.0.1369?

Regards,
Ken Takata

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-12 Fir de Conversatie Ken Takata
Hi,

2017/12/12 Tue 13:44:19 UTC+9 David Kotchan wrote:
> On Monday, December 11, 2017 at 7:06:37 AM UTC-8, Ken Takata wrote:
> 
> > I'm also aware the cursor behavior.
> > I have updated the "optimize-directx" branch in the vim-jp/vim repository.
> > gui_mch_flush() was called unnecessarily several times, and it caused the
> > behavior.
> > I think it is now fixed, but need more tests.
> 
> Hi Ken
> 
> Thanks for your work! However, I find that pulling code from the latest 
> branch (https://github.com/vim-jp/) does not help my problem. I tried 
> compiling it (under VS2017) with several different options:

Hmm, did you use the commit 0e7d0764cc24d7563a9eb8c97f3020274a52d09c on
the optimize-directx branch?
I still have no idea why it becomes slow on your environment.

Maybe we need to measure where the slow part is.
Or do we need to add an option to back to the old behavior?


> nmake /A /f Make_mvc.mak GUI=yes DIRECTX=yes MBYTE=yes CPUNR=sse2 
> OPTIMIZE=SPEED WINVER=0x0A00 FEATURES=HUGE all
> 
> nmake /A /f Make_mvc.mak GUI=yes DIRECTX=yes MBYTE=yes OPTIMIZE=SPEED 
> FEATURES=HUGE all
> (defaults to WINVER=0x0501, CPUNR=any)
> 
> and various other configurations, but I find it does not make a difference. 
> As before, under Win10 Pro at home, it is quite perfect, but under Win10 
> Enterprise at work, it is quite slow.
> 
> For what it's worth, I also tried launching using:
> 
> gvim -u NONE -U NONE -N -i NONE
> 
> and then later setting rop=type:directx (and encoding=utf-8, with a suitable 
> TrueType font) to see if that worked, but it did not.  As soon as rop was set 
> to directx, Vim would become slow.
> 
> I have also tried rop=type:directx,scrlines=1 (as you suggested), but I do 
> not find scrlines makes a difference.
> 
> Well, this seems like a hard problem to solve. For now I will stay at Vim 8 
> patched to 1366, or else I can disable DirectX (ie. no renderoptions) and 
> move ahead with 1376 or later if I need to gain the later patches.
> 
> I appreciate your time and efforts, it is much appreciated.  Your work over 
> the years has contributed very much to Vim functionality under Windows, 
> indeed!  Your skill and knowledge in C++/Win32 API is impressive.  Thanks for 
> your excellent work.

Thank you, too. ;-)

Regards,
Ken Takata

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-11 Fir de Conversatie David Kotchan
On Monday, December 11, 2017 at 7:06:37 AM UTC-8, Ken Takata wrote:

> I'm also aware the cursor behavior.
> I have updated the "optimize-directx" branch in the vim-jp/vim repository.
> gui_mch_flush() was called unnecessarily several times, and it caused the
> behavior.
> I think it is now fixed, but need more tests.

Hi Ken

Thanks for your work! However, I find that pulling code from the latest branch 
(https://github.com/vim-jp/) does not help my problem. I tried compiling it 
(under VS2017) with several different options:

nmake /A /f Make_mvc.mak GUI=yes DIRECTX=yes MBYTE=yes CPUNR=sse2 
OPTIMIZE=SPEED WINVER=0x0A00 FEATURES=HUGE all

nmake /A /f Make_mvc.mak GUI=yes DIRECTX=yes MBYTE=yes OPTIMIZE=SPEED 
FEATURES=HUGE all
(defaults to WINVER=0x0501, CPUNR=any)

and various other configurations, but I find it does not make a difference. As 
before, under Win10 Pro at home, it is quite perfect, but under Win10 
Enterprise at work, it is quite slow.

For what it's worth, I also tried launching using:

gvim -u NONE -U NONE -N -i NONE

and then later setting rop=type:directx (and encoding=utf-8, with a suitable 
TrueType font) to see if that worked, but it did not.  As soon as rop was set 
to directx, Vim would become slow.

I have also tried rop=type:directx,scrlines=1 (as you suggested), but I do not 
find scrlines makes a difference.

Well, this seems like a hard problem to solve. For now I will stay at Vim 8 
patched to 1366, or else I can disable DirectX (ie. no renderoptions) and move 
ahead with 1376 or later if I need to gain the later patches.

I appreciate your time and efforts, it is much appreciated.  Your work over the 
years has contributed very much to Vim functionality under Windows, indeed!  
Your skill and knowledge in C++/Win32 API is impressive.  Thanks for your 
excellent work.

--David 

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-11 Fir de Conversatie Ken Takata
Hi,

2017/12/11 Mon 2:48:13 UTC+9 jam...@zaltys.org wrote:
> Hi,
> 
> For me, page up / page down performance is much better with the recent 
> DirectX changes (running 1383). I'm on Windows 10 Fall Creators Update, Intel 
> HD630 graphics (latest driver).
> 
> But, when I use the mouse wheel or the window scroll bar to scroll one line 
> at a time, the block cursor momentarily moves out of position to the top or 
> bottom line.
> 
> Sometimes it lingers for like a second. It's quite visually distracting.
> 
> I ran old gvim (473) side-by-side with new gvim (1383), both with DirectX 
> rendering.
> 
> On old, if you watch closely, you can very vaguely perceive the cursor moving 
> out of position. But it moves back much, much quicker.
> 
> I don't notice this at all with GDI rendering.
> 
> 'scrlines' setting makes no difference.

I'm also aware the cursor behavior.
I have updated the "optimize-directx" branch in the vim-jp/vim repository.
gui_mch_flush() was called unnecessarily several times, and it caused the
behavior.
I think it is now fixed, but need more tests.

Regards,
Ken Takata

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-10 Fir de Conversatie jamesg
Hi,

For me, page up / page down performance is much better with the recent DirectX 
changes (running 1383). I'm on Windows 10 Fall Creators Update, Intel HD630 
graphics (latest driver).

But, when I use the mouse wheel or the window scroll bar to scroll one line at 
a time, the block cursor momentarily moves out of position to the top or bottom 
line.

Sometimes it lingers for like a second. It's quite visually distracting.

I ran old gvim (473) side-by-side with new gvim (1383), both with DirectX 
rendering.

On old, if you watch closely, you can very vaguely perceive the cursor moving 
out of position. But it moves back much, much quicker.

I don't notice this at all with GDI rendering.

'scrlines' setting makes no difference.

Regards,
James Grant.

On Sunday, 10 December 2017 07:28:21 UTC+13, Ken Takata  wrote:


> > > > On my machine at work, which is: Win10 Enterprise, OS build 15063.726, 
> > > > 64-bit, with an AMD Radeon R9 M370X video card, the rendering is much 
> > > > slower than (say) Vim 8 patched to 1366. The screen scrolling cannot 
> > > > keep up with ordinary j/k {up/down} keys held down, for example. Window 
> > > > refreshes are noticeably slow. There are various flickers here and 
> > > > there as the cursor redraws text items on screen during scrolling. 
> > > > These flickers are absent (or are so fast, as to be visually absent) on 
> > > > Vim 8 patch 1366 for example.
> > > 
> > > Oh, that is totally unexpected.



-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-10 Fir de Conversatie Ken Takata
Hi,

2017/12/7 Thu 22:34:17 UTC+9 Ken Takata wrote:
> Hi,
> 
> 2017/12/7 Thu 19:56:43 UTC+9 David Kotchan wrote:
> > On Saturday, December 2, 2017 at 7:03:33 AM UTC-8, K.Takata wrote:
> > 
> > > Hi,
> > > 
> > > This pull-request is a supplemental patch for #2375 (v8.0.1343).
> > > 
> > > This introduces some performance improvements and fixes a bug:
> > > 
> > > Improve performance when underlines, strikethroughs or undercurls are 
> > > used.
> > > 
> > > v8.0.1343 uses GDI to draw these lines, however, switching between 
> > > DirectX and GDI causes terrible slowdown.
> > > 
> > > This PR uses Direct2D APIs to draw the lines.
> > > 
> > > Improve performance when GDI fallback occurs by using a raster font.
> > > 
> > > This PR draws texts on top of a Direct2D surface even if a raster font is 
> > > selected.
> > > 
> > > Add 'scrlines' suboption to the 'rop' option for performance tuning.
> > > 
> > > On some environments, redrawing is faster than scrolling. (On my 
> > > environment, redrawing is about 2x faster.)
> > > 
> > > Users can optimize scrolling behavior by using this suboption.
> > > 
> > > Fix a bug that the 'mFallbackDC' variable was not properly updated.
> > > ...
> > 
> > I very much appreciate the work that went into the rendering improvements. 
> > This is great stuff.
> > 
> > But after compiling Vim 8 up to patch 1376 (Huge version with GUI; Visual 
> > Studio 2017), I am finding that rendering is quite slow on some systems.
> > 
> > On my machine at work, which is: Win10 Enterprise, OS build 15063.726, 
> > 64-bit, with an AMD Radeon R9 M370X video card, the rendering is much 
> > slower than (say) Vim 8 patched to 1366. The screen scrolling cannot keep 
> > up with ordinary j/k {up/down} keys held down, for example. Window 
> > refreshes are noticeably slow. There are various flickers here and there as 
> > the cursor redraws text items on screen during scrolling. These flickers 
> > are absent (or are so fast, as to be visually absent) on Vim 8 patch 1366 
> > for example.
> 
> Oh, that is totally unexpected.
> Does the behavior depends on the text you are editing?  The patch 8.0.1369
> should have improved the performance when showing underlines, undercurls, etc.
> Does the scroll speed change when the following setting is used?
> 
> set rop=type:directx,scrlines:1
> 
> 
> > On the other hand, on my machine at home, which is: Win10 Pro, OS build 
> > 15063.726, 64-bit, with an NVidia GeForce GTX 745 video card, there are no 
> > problems at all(!) Vim 8 patch 1376 is just as fast as patch 1366, and the 
> > new colored Emoji show up fine.
> > 
> > Both systems use the same monospace font (Roboto Mono) and have the same 
> > _vimrc, _gvimrc and plugins. No Vim functionality is impaired, just the 
> > drawing speed.
> > 
> > Does anyone has any ideas why rendering performance would be so different 
> > on what would seem to be two essentially identical operating systems and (I 
> > would have thought) more or less equally capable video cards?
> 

The most important difference between 8.0.1369 and before it is that 8.0.1369
uses Direct2D to draw underlines, undercurls, strikethroughs and also the
cursor.  Before 8.0.1369, GDI was used to draw the cursor, etc.
I still have no idea why the slowdown occurs on your environment, but one
possible cause would be the cursor drawing.
I'm trying to optimize the cursor drawing in the following URL:

  https://github.com/vim-jp/vim/pull/3

If you want to try this, please checkout the "optimize-directx" branch in
the vim-jp/vim repository.  E.g.

  git clone https://github.com/vim-jp/vim.git
  git checkout optimize-directx


More detail:

The gui_mch_flush() function is very slow when the directx renderer is used.
(E.g. it takes 0.7 ~ 1.5 msec or more on my note PC.)

When updating the cursor, functions are called in the following
sequence:

* out_flush()
* gui_update_cursor()
* gui_mch_flush()

However, out_flush() itself calls gui_mch_flush() from inside it
(through some functions).  Therefore gui_mch_flush() is called twice when
updating the cursor once.

I'm trying to reduce the call of gui_mch_flush() in the above branch,
however I don't know this can solve the reported problem.

Regards,
Ken Takata

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-09 Fir de Conversatie Ken Takata
Hi,

2017/12/10 Sun 2:40:29 UTC+9 Blay263 wrote:
> On Thursday, December 7, 2017 at 8:34:17 AM UTC-5, Ken Takata wrote:
> > Hi,
> > 
> > 2017/12/7 Thu 19:56:43 UTC+9 David Kotchan wrote:
> > > On Saturday, December 2, 2017 at 7:03:33 AM UTC-8, K.Takata wrote:
> > > 
> > > > Hi,
> > > > 
> > > > This pull-request is a supplemental patch for #2375 (v8.0.1343).
> > > > 
> > > > This introduces some performance improvements and fixes a bug:
> > > > 
> > > > Improve performance when underlines, strikethroughs or undercurls are 
> > > > used.
> > > > 
> > > > v8.0.1343 uses GDI to draw these lines, however, switching between 
> > > > DirectX and GDI causes terrible slowdown.
> > > > 
> > > > This PR uses Direct2D APIs to draw the lines.
> > > > 
> > > > Improve performance when GDI fallback occurs by using a raster font.
> > > > 
> > > > This PR draws texts on top of a Direct2D surface even if a raster font 
> > > > is selected.
> > > > 
> > > > Add 'scrlines' suboption to the 'rop' option for performance tuning.
> > > > 
> > > > On some environments, redrawing is faster than scrolling. (On my 
> > > > environment, redrawing is about 2x faster.)
> > > > 
> > > > Users can optimize scrolling behavior by using this suboption.
> > > > 
> > > > Fix a bug that the 'mFallbackDC' variable was not properly updated.
> > > > ...
> > > 
> > > I very much appreciate the work that went into the rendering 
> > > improvements. This is great stuff.
> > > 
> > > But after compiling Vim 8 up to patch 1376 (Huge version with GUI; Visual 
> > > Studio 2017), I am finding that rendering is quite slow on some systems.
> > > 
> > > On my machine at work, which is: Win10 Enterprise, OS build 15063.726, 
> > > 64-bit, with an AMD Radeon R9 M370X video card, the rendering is much 
> > > slower than (say) Vim 8 patched to 1366. The screen scrolling cannot keep 
> > > up with ordinary j/k {up/down} keys held down, for example. Window 
> > > refreshes are noticeably slow. There are various flickers here and there 
> > > as the cursor redraws text items on screen during scrolling. These 
> > > flickers are absent (or are so fast, as to be visually absent) on Vim 8 
> > > patch 1366 for example.
> > 
> > Oh, that is totally unexpected.
> > Does the behavior depends on the text you are editing?  The patch 8.0.1369
> > should have improved the performance when showing underlines, undercurls, 
> > etc.
> > Does the scroll speed change when the following setting is used?
> > 
> > set rop=type:directx,scrlines:1
> > 
> > 
> > > On the other hand, on my machine at home, which is: Win10 Pro, OS build 
> > > 15063.726, 64-bit, with an NVidia GeForce GTX 745 video card, there are 
> > > no problems at all(!) Vim 8 patch 1376 is just as fast as patch 1366, and 
> > > the new colored Emoji show up fine.
> > > 
> > > Both systems use the same monospace font (Roboto Mono) and have the same 
> > > _vimrc, _gvimrc and plugins. No Vim functionality is impaired, just the 
> > > drawing speed.
> > > 
> > > Does anyone has any ideas why rendering performance would be so different 
> > > on what would seem to be two essentially identical operating systems and 
> > > (I would have thought) more or less equally capable video cards?
> > 
> > 
> > Regards,
> > Ken Takata
> 
> After this update, I am having several issues :
> -y and g are cutoff
> -artifacts are left behind (see after pic below the status line)
> -status line is miss aligned

Does the attached patch fix the problem?
And what is your 'gfn' setting?

Regards,
Ken Takata

-- 
-- 
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.
diff --git a/src/gui_dwrite.cpp b/src/gui_dwrite.cpp
index e1d19db8d..e3e965902 100644
--- a/src/gui_dwrite.cpp
+++ b/src/gui_dwrite.cpp
@@ -995,7 +995,7 @@ DWriteContext::DrawText(const WCHAR *text, int len,
 
 	TextRenderer renderer(this);
 	TextRendererContext context = { color, FLOAT(cellWidth), 0.0f };
-	textLayout->Draw(&context, &renderer, FLOAT(x), FLOAT(y));
+	textLayout->Draw(&context, &renderer, FLOAT(x), FLOAT(y) - 0.5f);
 }
 
 SafeRelease(&textLayout);


Re: [vim/vim] Improve color emoji (#2401)

2017-12-09 Fir de Conversatie Blay263
On Thursday, December 7, 2017 at 8:34:17 AM UTC-5, Ken Takata wrote:
> Hi,
> 
> 2017/12/7 Thu 19:56:43 UTC+9 David Kotchan wrote:
> > On Saturday, December 2, 2017 at 7:03:33 AM UTC-8, K.Takata wrote:
> > 
> > > Hi,
> > > 
> > > This pull-request is a supplemental patch for #2375 (v8.0.1343).
> > > 
> > > This introduces some performance improvements and fixes a bug:
> > > 
> > > Improve performance when underlines, strikethroughs or undercurls are 
> > > used.
> > > 
> > > v8.0.1343 uses GDI to draw these lines, however, switching between 
> > > DirectX and GDI causes terrible slowdown.
> > > 
> > > This PR uses Direct2D APIs to draw the lines.
> > > 
> > > Improve performance when GDI fallback occurs by using a raster font.
> > > 
> > > This PR draws texts on top of a Direct2D surface even if a raster font is 
> > > selected.
> > > 
> > > Add 'scrlines' suboption to the 'rop' option for performance tuning.
> > > 
> > > On some environments, redrawing is faster than scrolling. (On my 
> > > environment, redrawing is about 2x faster.)
> > > 
> > > Users can optimize scrolling behavior by using this suboption.
> > > 
> > > Fix a bug that the 'mFallbackDC' variable was not properly updated.
> > > ...
> > 
> > I very much appreciate the work that went into the rendering improvements. 
> > This is great stuff.
> > 
> > But after compiling Vim 8 up to patch 1376 (Huge version with GUI; Visual 
> > Studio 2017), I am finding that rendering is quite slow on some systems.
> > 
> > On my machine at work, which is: Win10 Enterprise, OS build 15063.726, 
> > 64-bit, with an AMD Radeon R9 M370X video card, the rendering is much 
> > slower than (say) Vim 8 patched to 1366. The screen scrolling cannot keep 
> > up with ordinary j/k {up/down} keys held down, for example. Window 
> > refreshes are noticeably slow. There are various flickers here and there as 
> > the cursor redraws text items on screen during scrolling. These flickers 
> > are absent (or are so fast, as to be visually absent) on Vim 8 patch 1366 
> > for example.
> 
> Oh, that is totally unexpected.
> Does the behavior depends on the text you are editing?  The patch 8.0.1369
> should have improved the performance when showing underlines, undercurls, etc.
> Does the scroll speed change when the following setting is used?
> 
> set rop=type:directx,scrlines:1
> 
> 
> > On the other hand, on my machine at home, which is: Win10 Pro, OS build 
> > 15063.726, 64-bit, with an NVidia GeForce GTX 745 video card, there are no 
> > problems at all(!) Vim 8 patch 1376 is just as fast as patch 1366, and the 
> > new colored Emoji show up fine.
> > 
> > Both systems use the same monospace font (Roboto Mono) and have the same 
> > _vimrc, _gvimrc and plugins. No Vim functionality is impaired, just the 
> > drawing speed.
> > 
> > Does anyone has any ideas why rendering performance would be so different 
> > on what would seem to be two essentially identical operating systems and (I 
> > would have thought) more or less equally capable video cards?
> 
> 
> Regards,
> Ken Takata

After this update, I am having several issues :
-y and g are cutoff
-artifacts are left behind (see after pic below the status line)
-status line is miss aligned

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-07 Fir de Conversatie Ken Takata
Hi,

2017/12/7 Thu 19:56:43 UTC+9 David Kotchan wrote:
> On Saturday, December 2, 2017 at 7:03:33 AM UTC-8, K.Takata wrote:
> 
> > Hi,
> > 
> > This pull-request is a supplemental patch for #2375 (v8.0.1343).
> > 
> > This introduces some performance improvements and fixes a bug:
> > 
> > Improve performance when underlines, strikethroughs or undercurls are used.
> > 
> > v8.0.1343 uses GDI to draw these lines, however, switching between DirectX 
> > and GDI causes terrible slowdown.
> > 
> > This PR uses Direct2D APIs to draw the lines.
> > 
> > Improve performance when GDI fallback occurs by using a raster font.
> > 
> > This PR draws texts on top of a Direct2D surface even if a raster font is 
> > selected.
> > 
> > Add 'scrlines' suboption to the 'rop' option for performance tuning.
> > 
> > On some environments, redrawing is faster than scrolling. (On my 
> > environment, redrawing is about 2x faster.)
> > 
> > Users can optimize scrolling behavior by using this suboption.
> > 
> > Fix a bug that the 'mFallbackDC' variable was not properly updated.
> > ...
> 
> I very much appreciate the work that went into the rendering improvements. 
> This is great stuff.
> 
> But after compiling Vim 8 up to patch 1376 (Huge version with GUI; Visual 
> Studio 2017), I am finding that rendering is quite slow on some systems.
> 
> On my machine at work, which is: Win10 Enterprise, OS build 15063.726, 
> 64-bit, with an AMD Radeon R9 M370X video card, the rendering is much slower 
> than (say) Vim 8 patched to 1366. The screen scrolling cannot keep up with 
> ordinary j/k {up/down} keys held down, for example. Window refreshes are 
> noticeably slow. There are various flickers here and there as the cursor 
> redraws text items on screen during scrolling. These flickers are absent (or 
> are so fast, as to be visually absent) on Vim 8 patch 1366 for example.

Oh, that is totally unexpected.
Does the behavior depends on the text you are editing?  The patch 8.0.1369
should have improved the performance when showing underlines, undercurls, etc.
Does the scroll speed change when the following setting is used?

set rop=type:directx,scrlines:1


> On the other hand, on my machine at home, which is: Win10 Pro, OS build 
> 15063.726, 64-bit, with an NVidia GeForce GTX 745 video card, there are no 
> problems at all(!) Vim 8 patch 1376 is just as fast as patch 1366, and the 
> new colored Emoji show up fine.
> 
> Both systems use the same monospace font (Roboto Mono) and have the same 
> _vimrc, _gvimrc and plugins. No Vim functionality is impaired, just the 
> drawing speed.
> 
> Does anyone has any ideas why rendering performance would be so different on 
> what would seem to be two essentially identical operating systems and (I 
> would have thought) more or less equally capable video cards?


Regards,
Ken Takata

-- 
-- 
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.


Re: [vim/vim] Improve color emoji (#2401)

2017-12-07 Fir de Conversatie David Kotchan
On Saturday, December 2, 2017 at 7:03:33 AM UTC-8, K.Takata wrote:

> Hi,
> 
> This pull-request is a supplemental patch for #2375 (v8.0.1343).
> 
> This introduces some performance improvements and fixes a bug:
> 
> Improve performance when underlines, strikethroughs or undercurls are used.
> 
> v8.0.1343 uses GDI to draw these lines, however, switching between DirectX 
> and GDI causes terrible slowdown.
> 
> This PR uses Direct2D APIs to draw the lines.
> 
> Improve performance when GDI fallback occurs by using a raster font.
> 
> This PR draws texts on top of a Direct2D surface even if a raster font is 
> selected.
> 
> Add 'scrlines' suboption to the 'rop' option for performance tuning.
> 
> On some environments, redrawing is faster than scrolling. (On my environment, 
> redrawing is about 2x faster.)
> 
> Users can optimize scrolling behavior by using this suboption.
> 
> Fix a bug that the 'mFallbackDC' variable was not properly updated.
> ...

I very much appreciate the work that went into the rendering improvements. This 
is great stuff.

But after compiling Vim 8 up to patch 1376 (Huge version with GUI; Visual 
Studio 2017), I am finding that rendering is quite slow on some systems.

On my machine at work, which is: Win10 Enterprise, OS build 15063.726, 64-bit, 
with an AMD Radeon R9 M370X video card, the rendering is much slower than (say) 
Vim 8 patched to 1366. The screen scrolling cannot keep up with ordinary j/k 
{up/down} keys held down, for example. Window refreshes are noticeably slow. 
There are various flickers here and there as the cursor redraws text items on 
screen during scrolling. These flickers are absent (or are so fast, as to be 
visually absent) on Vim 8 patch 1366 for example.

On the other hand, on my machine at home, which is: Win10 Pro, OS build 
15063.726, 64-bit, with an NVidia GeForce GTX 745 video card, there are no 
problems at all(!) Vim 8 patch 1376 is just as fast as patch 1366, and the new 
colored Emoji show up fine.

Both systems use the same monospace font (Roboto Mono) and have the same 
_vimrc, _gvimrc and plugins. No Vim functionality is impaired, just the drawing 
speed.

Does anyone has any ideas why rendering performance would be so different on 
what would seem to be two essentially identical operating systems and (I would 
have thought) more or less equally capable video cards?

Thanks
--David Kotchan

-- 
-- 
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.