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.

Raspunde prin e-mail lui