[vim/vim] Improve color emoji (#2401)
K.Takata
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.
See the following URL for the change: vim-jp/vim@080e932
This PR was written by koron and me, and also reviewed by mattn.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/2401
Commit Summary
- Fix that mFallbackDC was not properly updated
- Improve GDI performance by using GdiInterop
- Add :: to C APIs
- Refactor
- No need to call GDI FillRect when using DirectX
- Optimize call of FlushInterop
- Refactor and improve performance
- Refactor FillRect
- Add comments
- Trivial changes
- Improve performance of SetPixel
- introduce DwraingMode to reduce switching
- check interop mode by mDMode
- to show diff beautifully
- Fix coding style
- Merge pull request #2 from vim-jp/drawing-mode
- Use redrawing instead of scrolling when DirectX is used
- Add srclines option to 'renderoptions'
- Remove needless flush
- Add error check for D2DERR_RECREATE_TARGET
- doc: Rewrite description for scrlines
- Fix syntax
- Adjust wording
File Changes
- M runtime/doc/options.txt (34)
- M src/gui_dwrite.cpp (273)
- M src/gui_dwrite.h (13)
- M src/gui_w32.c (177)
Patch Links:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
David Kotchan
> 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
Ken Takata
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
Ken Takata
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
jam...@zaltys.org
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:
<snip>
> > > > 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.
Ken Takata
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
David Kotchan
> 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
Ken Takata
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
Ken Takata
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
David Kotchan
> > 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
David Kotchan
> 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
Ken Takata
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
David Kotchan
>
> 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
Ken Takata
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
David Kotchan
> 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
