Hi,

I have a small patch for GVIM (Win32) that improves display performance. On my laptop (WinXP with nVidia graphics), half/full page scrolling in GVIM is quite slow due to the refresh required for the GVIM window. I tracked this down to src/gui_w48.c:gui_mch_delete_lines(). A comment in this function states:

     /* The SW_INVALIDATE is required when part of the window is covered or
      * off-screen.  How do we avoid it when it's not needed? */

It is this invalidation of the window region which is the problem. The solution is to only use the SW_INVALIDATE flag when the GVIM window is obscured. To determine if a window is obscured, refer to Microsoft KB Q75236.

cheers

--- gui_w48.c.orig      Thu Oct 02 16:48:00 2003
+++ gui_w48.c   Thu Oct 02 17:33:44 2003
@@ -2360,16 +2360,34 @@
      int           num_lines)
  {
      RECT      rc;
+    RECT       rcVim, rcOther, rcDest;
+    HWND       hPrevWnd, hNextWnd;
+    UINT       flags = NULL;

      rc.left = FILL_X(gui.scroll_region_left);
      rc.right = FILL_X(gui.scroll_region_right + 1);
      rc.top = FILL_Y(row);
      rc.bottom = FILL_Y(gui.scroll_region_bot + 1);
      /* The SW_INVALIDATE is required when part of the window is covered or
-     * off-screen.  How do we avoid it when it's not needed? */
-    ScrollWindowEx(s_textArea, 0, -num_lines * gui.char_height,
-           &rc, &rc, NULL, NULL, SW_INVALIDATE);
+     * off-screen. Refer to MS KB Q75236. */
+
+    GetWindowRect(s_hwnd, &rcVim);
+
+    for (hPrevWnd = s_hwnd ;
+         hNextWnd = GetWindow(hPrevWnd, GW_HWNDPREV) ;
+         hPrevWnd = hNextWnd)
+    {
+        GetWindowRect(hNextWnd, &rcOther);
+        if (IsWindowVisible(hNextWnd) &&
+            IntersectRect(&rcDest, &rcVim, &rcOther))
+        {
+            flags = SW_INVALIDATE;
+            break;
+        }
+    }

+    ScrollWindowEx(s_textArea, 0, -num_lines * gui.char_height,
+           &rc, &rc, NULL, NULL, flags);
      UpdateWindow(s_textArea);
      /* This seems to be required to avoid the cursor disappearing when
       * scrolling such that the cursor ends up in the top-left character on

--- gui_w48.c.orig Thu Oct 02 16:48:00 2003
+++ gui_w48.c Thu Oct 02 17:33:44 2003
@@ -2360,16 +2360,34 @@
      int     num_lines)
  {
      RECT rc;
+    RECT rcVim, rcOther, rcDest;
+    HWND hPrevWnd, hNextWnd;
+    UINT flags = NULL;

      rc.left = FILL_X(gui.scroll_region_left);
      rc.right = FILL_X(gui.scroll_region_right + 1);
      rc.top = FILL_Y(row);
      rc.bottom = FILL_Y(gui.scroll_region_bot + 1);
      /* The SW_INVALIDATE is required when part of the window is covered or
-     * off-screen.  How do we avoid it when it's not needed? */
-    ScrollWindowEx(s_textArea, 0, -num_lines * gui.char_height,
-     &rc, &rc, NULL, NULL, SW_INVALIDATE);
+     * off-screen. Refer to MS KB Q75236. */
+
+    GetWindowRect(s_hwnd, &rcVim);
+
+    for (hPrevWnd = s_hwnd ;
+         hNextWnd = GetWindow(hPrevWnd, GW_HWNDPREV) ;
+         hPrevWnd = hNextWnd)
+    {
+        GetWindowRect(hNextWnd, &rcOther);
+        if (IsWindowVisible(hNextWnd) &&
+            IntersectRect(&rcDest, &rcVim, &rcOther))
+        {
+            flags = SW_INVALIDATE;
+            break;
+        }
+    }

+    ScrollWindowEx(s_textArea, 0, -num_lines * gui.char_height,
+     &rc, &rc, NULL, NULL, flags);
      UpdateWindow(s_textArea);
      /* This seems to be required to avoid the cursor disappearing when
       * scrolling such that the cursor ends up in the top-left character on

I haven't done any benchmarking, but seems to work
nicely on my Win2k box. Thanks :)

> -----Original Message-----
> From: Michael Wookey (AU) [SMTP:michael.wookey@...]
> Sent: Thursday, October 02, 2003 8:57 AM
> To: vim-dev@...
> Subject: Patch - Win32 GVIM (SW_INVALIDATE)
>
> /Hi,
>
> I have a small patch for GVIM (Win32) that improves display performance.
> On my laptop (WinXP with nVidia graphics), half/full page scrolling in
> GVIM is quite slow due to the refresh required for the GVIM window. I
> tracked this down to src/gui_w48.c:gui_mch_delete_lines(). A comment in
> this function states:
>
>      /* The SW_INVALIDATE is required when part of the window is covered
> or
>       * off-screen.  How do we avoid it when it's not needed? */
>
> It is this invalidation of the window region which is the problem. The
> solution is to only use the SW_INVALIDATE flag when the GVIM window is
> obscured. To determine if a window is obscured, refer to Microsoft KB
> Q75236.
>
> cheers
>
Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

Michael Wookey wrote:

> I have a small patch for GVIM (Win32) that improves display
> performance. On my laptop (WinXP with nVidia graphics), half/full page
> scrolling in GVIM is quite slow due to the refresh required for the
> GVIM window. I tracked this down to
> src/gui_w48.c:gui_mch_delete_lines(). A comment in this function
> states:
>
>      /* The SW_INVALIDATE is required when part of the window is covered or
>       * off-screen.  How do we avoid it when it's not needed? */
>
> It is this invalidation of the window region which is the problem. The
> solution is to only use the SW_INVALIDATE flag when the GVIM window is
> obscured. To determine if a window is obscured, refer to Microsoft KB
> Q75236.

Thanks for making this patch.

How much (scrolling) speed do we gain by this?

Does this also work for Win16? (Vince?)

--
Proof techniques #2: Proof by Oddity.
	 SAMPLE: To prove that horses have an infinite number of legs.
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
     legs for a horse.
(4) But the only number that is both odd and even is infinity.
(5) Therefore, horses must have an infinite number of legs.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Minor bug -

On 2 Oct 2003 at 17:57, Michael Wookey (AU) wrote:

> +    UINT flags = NULL;

Warning on assigning a pointer to an integer, at least for those
compilers that define NULL as (void*)0;

Mike
--
Damnation: A beaver colony.

In message <34611C909B4FD611BB2000508BA8EEEA02D09299@...
m.au> of Thu, 2 Oct 2003 17:57:26 in , "Michael Wookey (AU)"
<michael.wookey@...> writes
>
>Hi,
>
>I have a small patch for GVIM (Win32) that improves display
>performance. On my laptop (WinXP with nVidia graphics), half/full page
>scrolling in GVIM is quite slow due to the refresh required for the
>GVIM window. I tracked this down to src/gui_w
>48.c:gui_mch_delete_lines(). A comment in this function states:
>
>     /* The SW_INVALIDATE is required when part of the window is
>covered or
>      * off-screen.  How do we avoid it when it's not needed? */
>
>It is this invalidation of the window region which is the problem. The
>solution is to only use the SW_INVALIDATE flag when the GVIM window is
>obscured. To determine if a window is obscured, refer to Microsoft KB
>Q75236.
>
>cheers
>
>--- gui_w48.c.orig      Thu Oct 02 16:48:00 2003
>+++ gui_w48.c   Thu Oct 02 17:33:44 2003
[snip]
>[ A MIME text / plain part was included here. ]
I take it that this is your first patch. We all start somewhere ;-) I
find "quite slow" needlessly qualitative where I want to see
quantitative data. I tested on a 4514 line file with 45 lines displayed
per screen by holding down the "Page Dn" button with gvim in full screen
mode. My laptop runs Win2K with an "ATI RAGE MOBILITY-M1 AGP2X
(English)" display adapter. My base system is gvim 6.2 with no patches
applied. I timed by doing 1 and 2 and ... and estimated 16 seconds
before and after applying the patch. The patch gave a diagnostic with
Visual C++ 6.0 and the command line 'nmake /f Make_ivc.mak cfg="Vim -
Win32 Debug gvim OLE"'. I changed "UINT flags = NULL" to "UINT  flags =
0". Bram has a patch form relative to the parent directory which makes
him more comfortable. I have recast the change so. At the moment, my
opinion is that the patch should NOT be applied. I hope:
1) somebody will tell me a better way of timing a test;
2) somebody will supply a scenario with numbers justifying the
application of the patch.

*** src/gui_w48.c.0     Sun May 25 16:26:06 2003
--- src/gui_w48.c       Thu Oct  2 09:21:21 2003
***************
*** 2360,2375 ****
       int           num_lines)
   {
       RECT      rc;

       rc.left = FILL_X(gui.scroll_region_left);
       rc.right = FILL_X(gui.scroll_region_right + 1);
       rc.top = FILL_Y(row);
       rc.bottom = FILL_Y(gui.scroll_region_bot + 1);
       /* The SW_INVALIDATE is required when part of the window is covered or
!      * off-screen.  How do we avoid it when it's not needed? */
!     ScrollWindowEx(s_textArea, 0, -num_lines * gui.char_height,
!           &rc, &rc, NULL, NULL, SW_INVALIDATE);

       UpdateWindow(s_textArea);
       /* This seems to be required to avoid the cursor disappearing when
        * scrolling such that the cursor ends up in the top-left character on
--- 2360,2393 ----
       int           num_lines)
   {
       RECT      rc;
+     RECT      rcVim, rcOther, rcDest;
+     HWND      hPrevWnd, hNextWnd;
+     UINT      flags = 0;

       rc.left = FILL_X(gui.scroll_region_left);
       rc.right = FILL_X(gui.scroll_region_right + 1);
       rc.top = FILL_Y(row);
       rc.bottom = FILL_Y(gui.scroll_region_bot + 1);
       /* The SW_INVALIDATE is required when part of the window is covered or
!      * off-screen. Refer to MS KB Q75236. */
!
!     GetWindowRect(s_hwnd, &rcVim);

+     for (hPrevWnd = s_hwnd ;
+          hNextWnd = GetWindow(hPrevWnd, GW_HWNDPREV) ;
+          hPrevWnd = hNextWnd)
+     {
+         GetWindowRect(hNextWnd, &rcOther);
+         if (IsWindowVisible(hNextWnd) &&
+             IntersectRect(&rcDest, &rcVim, &rcOther))
+         {
+             flags = SW_INVALIDATE;
+             break;
+         }
+     }
+
+     ScrollWindowEx(s_textArea, 0, -num_lines * gui.char_height,
+           &rc, &rc, NULL, NULL, flags);
       UpdateWindow(s_textArea);
       /* This seems to be required to avoid the cursor disappearing when
        * scrolling such that the cursor ends up in the top-left character on

BTW. It seems wasteful of bandwidth to send your message in both text
and html. Are you able to eliminate the html?
--
Walter Briscoe

It appears to work for Win16 too (at least doesn't
break anything)

I tried scrolling through the tags file on a vanilla
and patched build - hard to be precise as my machine
is too fast ;)

I got the impression that a slight speedup (10%) was
evident, but this was using the high-precision timer
of my watch's second hand ;)

> -----Original Message-----
> From: Bram Moolenaar [SMTP:Bram@...]
>
>
> How much (scrolling) speed do we gain by this?
>
> Does this also work for Win16? (Vince?)
>
Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

I agree that there is around a 10% improvement when simply scrolling through a
large file. I found the best and most visible improvement of the patch is when a
command such as

:map or :history

is used (to force scrolling). At least on my setup, the improvement is very
visible - nearing the performance of console VIM. I'm sure on other systems the
visible improvement may not be as noticible, but on my (slow) setup waiting for
paint redraws is annoying. Unfortunately, not everyone has a fast video card.

cheers

-----Original Message-----
From: Vince Negri [mailto:vnegri@...]
Sent: Thursday, 2 October 2003 7:55 PM
To: 'Bram Moolenaar'
Cc: vim-dev@...
Subject: RE: Patch - Win32 GVIM (SW_INVALIDATE)


It appears to work for Win16 too (at least doesn't
break anything)
I tried scrolling through the tags file on a vanilla
and patched build - hard to be precise as my machine
is too fast ;)

I got the impression that a slight speedup (10%) was
evident, but this was using the high-precision timer
of my watch's second hand ;)

  > -----Original Message-----
  > From: Bram Moolenaar [SMTP:Bram@...]
  >
  >
  > How much (scrolling) speed do we gain by this?
  >
  > Does this also work for Win16? (Vince?)
  >
Legal Disclaimer: Any views expressed by the sender of this message are not
necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient only, no
mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

Hmm, would gu_mch_insert_lines() in gui_w48.c benefit from similar
logic?  And could there be an optimisation to skip the loop check for
intersecting window rects as long as focus and/or window position has
not changed?

2p's worth.

On 2 Oct 2003 at 11:39, Bram Moolenaar wrote:

>
> Michael Wookey wrote:
>
> > I have a small patch for GVIM (Win32) that improves display
> > performance. On my laptop (WinXP with nVidia graphics), half/full page
> > scrolling in GVIM is quite slow due to the refresh required for the
> > GVIM window. I tracked this down to
> > src/gui_w48.c:gui_mch_delete_lines(). A comment in this function
> > states:
> >
> >      /* The SW_INVALIDATE is required when part of the window is covered or
> >       * off-screen.  How do we avoid it when it's not needed? */
> >
> > It is this invalidation of the window region which is the problem. The
> > solution is to only use the SW_INVALIDATE flag when the GVIM window is
> > obscured. To determine if a window is obscured, refer to Microsoft KB
> > Q75236.
>
> Thanks for making this patch.
>
> How much (scrolling) speed do we gain by this?
>
> Does this also work for Win16? (Vince?)
>
> --
> Proof techniques #2: Proof by Oddity.
>  SAMPLE: To prove that horses have an infinite number of legs.
> (1) Horses have an even number of legs.
> (2) They have two legs in back and fore legs in front.
> (3) This makes a total of six legs, which certainly is an odd number of
>     legs for a horse.
> (4) But the only number that is both odd and even is infinity.
> (5) Therefore, horses must have an infinite number of legs.
>
>  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
> ///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
> \\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
>  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Mike
--
Belladonna:  In Italian, a beautiful lady; in English a deadly poison.

Yes, gui_mch_insert_lines() should follow the same logic. I had also previously
thought about the optimisations you mention and am currently investigating.

cheers


Mike Williams wrote:

> Hmm, would gu_mch_insert_lines() in gui_w48.c benefit from similar
> logic?  And could there be an optimisation to skip the loop check for
> intersecting window rects as long as focus and/or window position has
> not changed?
>
> 2p's worth.
>
> On 2 Oct 2003 at 11:39, Bram Moolenaar wrote:
>
>
>>Michael Wookey wrote:
>>
>>
>>>I have a small patch for GVIM (Win32) that improves display
>>>performance. On my laptop (WinXP with nVidia graphics), half/full page
>>>scrolling in GVIM is quite slow due to the refresh required for the
>>>GVIM window. I tracked this down to
>>>src/gui_w48.c:gui_mch_delete_lines(). A comment in this function
>>>states:
>>>
>>>     /* The SW_INVALIDATE is required when part of the window is covered or
>>>      * off-screen.  How do we avoid it when it's not needed? */
>>>
>>>It is this invalidation of the window region which is the problem. The
>>>solution is to only use the SW_INVALIDATE flag when the GVIM window is
>>>obscured. To determine if a window is obscured, refer to Microsoft KB
>>>Q75236.
>>
>>Thanks for making this patch.
>>
>>How much (scrolling) speed do we gain by this?
>>
>>Does this also work for Win16? (Vince?)
>>
>>--
>>Proof techniques #2: Proof by Oddity.
>> SAMPLE: To prove that horses have an infinite number of legs.
>>(1) Horses have an even number of legs.
>>(2) They have two legs in back and fore legs in front.
>>(3) This makes a total of six legs, which certainly is an odd number of
>>    legs for a horse.
>>(4) But the only number that is both odd and even is infinity.
>>(5) Therefore, horses must have an infinite number of legs.
>>
>> /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
>>///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
>>\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
>> \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///
>
>
> Mike

hey all,

I noticed that vim doesn't come bundled with gvim, ie: on win32 you are
forced to use the GUI.

Is this true? or is there an option which allows you to use the text
version of vim via a flag or some such? And if not, how easy would it be
to bundle the text version of vim in the future? (I don't want to be
forced to get cygwin just to use vim)

thanks much,

Ed

On Thu, Oct 02, 2003 at 12:26:43PM -0700, esp@... wrote:

> Is this true? or is there an option which allows you to use the text
> version of vim via a flag or some such? And if not, how easy would it be
> to bundle the text version of vim in the future? (I don't want to be
> forced to get cygwin just to use vim)

gvim -v should work.

You should also be able to rename the executable to vim.exe.

Dave

Hi,

I've tidied up this patch based upon the feedback received so far and obtained
some benchmarks. The "region check" only occurs in the following cases:

   - after the window is resized
   - after the window is moved
   - after the window obtains focus

These handle the cases where there may be an "always on top" window overlapping
gvim as the gvim window may have been resized (but now under another window), or
moved (and may be offscreen/under another window). The calculation is always
done when gvim gets focus incase there may be other "on top" windows obscuring
the main gvim window.

Changes:
    src/gui_w16.c  -  Enable WM_MOVE
    src/gui_w32.c  -  Enable WM_MOVE
    src/gui_w48.c :

The flag passed to ScrollWindowEx() is a global stored in "s_scroll_flags". A
new function "calc_scroll_flags()" performs the region calculations and sets
s_scroll_flags = SW_INVALIDATE if necessary.

calc_scroll_flags() is called by the following: _OnMove(), _OnSetFocus() and
_OnSize().

Some benchmarks:

    set lines=60
    :e [various files below]
    CTRL+w s

With a split screen I obtained the following timings for scrolling through the
entire file via CTRL+f held down:

src/screen.c
    with patch:     33 seconds
    without patch: 148 seconds

src/option.c
    with patch:     37 seconds
    without patch: 165 seconds

src/eval.c
    with patch:     36 seconds
    without patch: 179 seconds

cheers


Mike Williams wrote:

> Hmm, would gu_mch_insert_lines() in gui_w48.c benefit from similar
> logic?  And could there be an optimisation to skip the loop check for
> intersecting window rects as long as focus and/or window position has
> not changed?
>
> 2p's worth.

--- src\gui_w32.c.orig Fri Oct 03 09:30:00 2003
+++ src\gui_w32.c Fri Oct 03 09:30:09 2003
@@ -579,7 +579,7 @@
  #ifdef FEAT_MENU
 	 HANDLE_MSG(hwnd, WM_COMMAND, _OnMenu);
  #endif
- /* HANDLE_MSG(hwnd, WM_MOVE,     _OnMove); */
+ HANDLE_MSG(hwnd, WM_MOVE,     _OnMove);
 	 /* HANDLE_MSG(hwnd, WM_NCACTIVATE,  _OnNCActivate); */
 	 HANDLE_MSG(hwnd, WM_SETFOCUS, _OnSetFocus);
 	 HANDLE_MSG(hwnd, WM_SIZE, _OnSize);
--- src\gui_w16.c.orig Fri Oct 03 09:27:10 2003
+++ src\gui_w16.c Fri Oct 03 09:27:47 2003
@@ -188,7 +188,7 @@
  #ifdef FEAT_MENU
 	 HANDLE_MSG(hwnd, WM_COMMAND, _OnMenu);
  #endif
- /* HANDLE_MSG(hwnd, WM_MOVE,     _OnMove); */
+ HANDLE_MSG(hwnd, WM_MOVE,     _OnMove);
 	 /* HANDLE_MSG(hwnd, WM_NCACTIVATE,  _OnNCActivate); */
 	 HANDLE_MSG(hwnd, WM_SETFOCUS, _OnSetFocus);
 	 HANDLE_MSG(hwnd, WM_SIZE, _OnSize);
--- src\gui_w48.c.orig Thu Oct 02 16:48:00 2003
+++ src\gui_w48.c Fri Oct 03 09:35:53 2003
@@ -182,6 +182,7 @@
   */
  static int allow_scrollbar = FALSE;

+static int s_scroll_flags = 0; /* The flags used in ScrollWindowEx() */

  #ifdef GLOBAL_IME
  # undef DefWindowProc
@@ -1446,6 +1447,34 @@
  }

  /*
+ * Calculate if we need to set SW_INVALIDATE when scrolling. This is
+ * only required if the main window is obscured.
+ */
+    static void
+calc_scroll_flags(void)
+{
+    RECT rcVim, rcOther, rcDest;
+    HWND hPrevWnd, hNextWnd;
+
+    s_scroll_flags = 0;
+
+    GetWindowRect(s_hwnd, &rcVim);
+
+    for (hPrevWnd = s_hwnd ;
+         hNextWnd = GetWindow(hPrevWnd, GW_HWNDPREV) ;
+         hPrevWnd = hNextWnd)
+    {
+        GetWindowRect(hNextWnd, &rcOther);
+        if (IsWindowVisible(hNextWnd) &&
+            IntersectRect(&rcDest, &rcVim, &rcOther))
+        {
+            s_scroll_flags = SW_INVALIDATE;
+            break;
+        }
+    }
+}
+
+/*
   * Process a single Windows message.
   * If one is not available we hang until one is.
   */
@@ -2194,15 +2223,26 @@
 	 /* Menu bar may wrap differently now */
 	 gui_mswin_get_menu_height(TRUE);
  #endif
+ calc_scroll_flags();
      }
  }

      static void
+_OnMove(
+    HWND hwnd,
+    int x,
+    int y)
+{
+    calc_scroll_flags();
+}
+
+    static void
  _OnSetFocus(
      HWND hwnd,
      HWND hwndOldFocus)
  {
      gui_focus_change(TRUE);
+    calc_scroll_flags();
      (void)DefWindowProc(hwnd, WM_SETFOCUS, (WPARAM)hwndOldFocus, 0);
  }

@@ -2365,10 +2405,8 @@
      rc.right = FILL_X(gui.scroll_region_right + 1);
      rc.top = FILL_Y(row);
      rc.bottom = FILL_Y(gui.scroll_region_bot + 1);
-    /* The SW_INVALIDATE is required when part of the window is covered or
-     * off-screen.  How do we avoid it when it's not needed? */
      ScrollWindowEx(s_textArea, 0, -num_lines * gui.char_height,
-     &rc, &rc, NULL, NULL, SW_INVALIDATE);
+     &rc, &rc, NULL, NULL, s_scroll_flags);

      UpdateWindow(s_textArea);
      /* This seems to be required to avoid the cursor disappearing when
@@ -2397,10 +2435,8 @@
      rc.right = FILL_X(gui.scroll_region_right + 1);
      rc.top = FILL_Y(row);
      rc.bottom = FILL_Y(gui.scroll_region_bot + 1);
-    /* The SW_INVALIDATE is required when part of the window is covered or
-     * off-screen.  How do we avoid it when it's not needed? */
      ScrollWindowEx(s_textArea, 0, num_lines * gui.char_height,
-     &rc, &rc, NULL, NULL, SW_INVALIDATE);
+     &rc, &rc, NULL, NULL, s_scroll_flags);

      gui_undraw_cursor(); /* Is this really necessary? */
      UpdateWindow(s_textArea);

Er no. Renaming doesn't work with win32, sorry David.

This question has been asked before, and the answer was something along
the lines that there a bunch of potentially different versions of
vim.exe that could sensibly be deployed, and that Bram was unable to
choose any one of them (yes?).

I tend to make my own deployment that includes a vim.exe ..  I find it
very useful.  The one I choose to use is the win32 console version.

//.ichael G.

-----Original Message-----
From: David Brown [mailto:vim@...]
Sent: Friday, 3 October 2003 6:00 AM
To: esp@...
Cc: Vim Developer Discussion
Subject: Re: bundling of vim.exe with gvim distribution


On Thu, Oct 02, 2003 at 12:26:43PM -0700, esp@... wrote:

> Is this true? or is there an option which allows you to use the text
> version of vim via a flag or some such? And if not, how easy would it
> be to bundle the text version of vim in the future? (I don't want to
> be forced to get cygwin just to use vim)

gvim -v should work.

You should also be able to rename the executable to vim.exe.

Dave

Hello,

I am playing lately with xpm format and look into existing
examples. I looked into vimlogo.xpm from standard sources
and noticed graphic is declared twice. Removing of one of them
nothing breaks. Size of Vim distribution can be reduced 8k. Yay :)

m.
--
LaTeX + Vim = http://vim-latex.sourceforge.net/
Vim-list(s) Users Map: (last change 12 Sep)
  http://skawina.eu.org/mikolaj/vimlist
Are You There?

Hi,

On 3 Oct 2003 at 14:06, Michael Wookey wrote:

> I've tidied up this patch based upon the feedback received so far and obtained
> some benchmarks.

The patch looks good to me.

> Some benchmarks:
>
>    set lines=60
>    :e [various files below]
>    CTRL+w s
>
> With a split screen I obtained the following timings for scrolling through the
> entire file via CTRL+f held down:
>
> src/screen.c
>    with patch:     33 seconds
>    without patch: 148 seconds
>
> src/option.c
>    with patch:     37 seconds
>    without patch: 165 seconds
>
> src/eval.c
>    with patch:     36 seconds
>    without patch: 179 seconds
>
> cheers

You do really have a slow laptop .  This should make people on lower
powered Windows machines a lot happoer I would think.

TTFN

Mike
--
Cthulhu loves you - with ketchup.

Mikolaj Machowski wrote:

> I am playing lately with xpm format and look into existing
> examples. I looked into vimlogo.xpm from standard sources
> and noticed graphic is declared twice. Removing of one of them
> nothing breaks. Size of Vim distribution can be reduced 8k. Yay :)

Where did you find these two copies?

--
Ed's Radiator Shop: The Best Place in Town to Take a Leak.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Michael Geddes wrote:

> Er no. Renaming doesn't work with win32, sorry David.
>
> This question has been asked before, and the answer was something along
> the lines that there a bunch of potentially different versions of
> vim.exe that could sensibly be deployed, and that Bram was unable to
> choose any one of them (yes?).

On Unix a program always starts with just stdin/stdout/stderr and has to
open a connection to the X server to start using windows.  On MS-Windows
a program is either a "DOS" program or a "Windows" program.  I don't
think it is possible, or at least it is not easy, to have a program that
starts in a DOS console and starts opening windows after that.  Thus you
can't make Vim run in a console or open windows by adding a command line
option.

It would be possible to make a wrapper that starts vim.exe or gvim.exe
depending on an argument, but you still need the two executables, thus
it doesn't make much sense.

--
hundred-and-one symptoms of being an internet addict:
83. Batteries in the TV remote now last for months.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

> On Unix a program always starts with just stdin/stdout/stderr and
> has to
> open a connection to the X server to start using windows.  On
> MS-Windows
> a program is either a "DOS" program or a "Windows" program.  I don't

Technical term is "Console mode".  DOS has nothing to do with it, and
good riddance! :)

> think it is possible, or at least it is not easy, to have a program
> that
> starts in a DOS console and starts opening windows after that.  Thus
> you
> can't make Vim run in a console or open windows by adding a command
> line
> option.

Actually, the only difference between a console and a windows mode
program is that the console mode program automatically gets a console.
It either attaches to the parent's console or has a console created for
it (if the parent isn't attached to a console).  A "Windows" mode app is
born without a console.  Otherwise, both systems are the same -- both can
do the same kind of GUIs and Windowing.  A Windows Mode app can create a
console or attach itself to an existing console.  Most of the time, that
works ok, but all too often we want to have our cake and eat it, too.

I keep on running into this -- how can you make a "dual" mode
application?  I've never tried it, but I think it is possible.  Three
possible solutions come to mind:

1.  Create a Windows mode program.  At startup, decide whether you really
want to be Windows or Console.  If you want to be Windows, no problem,
just do what you usually do.  If you want to be a console app, call
AllocConsole() (this allocates a console and attaches the process to it),
and then continue on as a console app.  The only issue is that the C
Runtime might not be immediately conviced that you are a console app.  I
haven't tried it, but I find it easy to imagine that the C Runtime
startup code could set itself up differently depending on whether you are
a console app or a windows app.  I don't think it would be a problem, but
it is possible.  If it is a problem, I think I know what the workaround
would be...

The only disadvantage to this is that you are on a different console from
the process that spawned you.  The expected behavior would be to have a
new console pop up if you start vim from a GUI, but for vim to be in the
original console if started from the command line.

2.  Create a console mode program.  At startup, if you decide that you
want to be a Windows app after all, just call FreeConsole() to detach
from the console you're attached to.

The disadvantage here is that you'll start out a console no matter what.
If you start from the command line, this isn't a problem -- you start
with the parent's console, then detach from it, and all is well.  But if
you are spawned by a process without a console, a new console will be
created for you.  You can detach from it immediately, but there will be a
brief flicker of a console popping up and then disappearing.

3.  Create a Windows mode program.  If you want to be on a console, call
AttachConsole(ATTACH_PARENT_PROCESS).  I think the call will fail if the
parent doesn't have a console, in which case you just call
AllocConsole().

So now you're wondering why I didn't just give #3.  Turns out that this
didn't become an option until Windows XP.  Windows 2000 and earlier
cannot attach to an existing console -- processes either take the console
they are born with or they create a new console.

> It would be possible to make a wrapper that starts vim.exe or
> gvim.exe
> depending on an argument, but you still need the two executables,
> thus
> it doesn't make much sense.

Strangely enough, it seems that Microsoft agrees with you.  Check this
out if you have Visual Studio.  If you have 6.0, go to Program
Files\Microsoft Visual Studio\Common\MsDev98\bin and look at MSDEV.  If
you have 7.x, go to Program Files\Microsoft Visual ...\Common7\IDE and
look at DEVENV.

Note that there are two versions of each -- msdev.EXE and msdev.COM,
devenv.EXE and devenv.COM.  COM-type programs are a very old style, and
are DOS only.  It turns out that these really aren't COM programs --
they're EXE style programs that have been renamed.  Windows uses the file
extension to determine whether or not a file is executable, but looks
inside the file to figure out how to execute it, so it runs the COM file
properly as if it were an EXE program.  And since by default the system
looks for COM files before it looks for EXE files (legacy rule that was
instituted while I was still in kindergarten), if you type MSDEV at the
command prompt, it will run the COM program.  But all of the shortcuts
are to the EXE.

The COM program is a console mode app.  The EXE program is a windows mode
app.  Microsoft is using method #2 from above.  All of the shortcuts go
to the EXE version so that you don't get the console popping up if you
start MSDEV from a GUI.  But if you double-click on MSDEV.COM, you'll see
a brief flicker of a console appearing and disappearing, then MSDEV.EXE
will start up.

All MSDEV.COM is doing is starting up MSDEV.EXE.  The purpose is so that
the main program, MSDEV.EXE doesn't have the flickering console popup,
yet MSDEV can still be used as a command line utility.  MSDEV.COM simply
starts MSDEV.EXE, passing it the exact same command line parameters as it
got.  Even though MSDEV.EXE can't have MSDEV.COM's console, it DOES
inherit MSDEV.COM's StdIn, StdOut, and StdErr handles.  So it can't do
ncurses-style stuff, but it CAN send text to the console, which is all it
needs to be able to do.

MSDEV.COM does have one job to do: it has to decide whether or not to
wait for MSDEV.EXE to exit.  If the user just typed MSDEV with no
parameters or with the name of a source file, he/she probably just wants
to start the IDE, so MSDEV.COM starts the IDE, then exits while the IDE
continues running.  But if the user types MSDEV MyProject.dsp /MAKE
Debug, they want MSDEV to build MyProject.  So MSDEV.COM starts the IDE,
then waits for it to exit before exiting itself.  This way, you can run
MSDEV /MAKE from a batch file, and the batch file won't continue until
the make has completed.

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!

Michael Wookey wrote:

> I've tidied up this patch based upon the feedback received so far and
> obtained some benchmarks. The "region check" only occurs in the
> following cases:
>
>   - after the window is resized
>   - after the window is moved
>   - after the window obtains focus
>
> These handle the cases where there may be an "always on top" window
> overlapping gvim as the gvim window may have been resized (but now
> under another window), or moved (and may be offscreen/under another
> window). The calculation is always done when gvim gets focus incase
> there may be other "on top" windows obscuring the main gvim window.

It looks like this doesn't take care of another program opening a popup
window (splash window) without a focus change.  This may happen when Vim
is busy with a slow script, or another program is popping up a window
without obtaining focus.

Is the gain in speed for avoiding the check for overlaps enough to
justify adding these tricks?  It's very bad to add code that may have
obscure problems that happen in rare situations.

--
hundred-and-one symptoms of being an internet addict:
88. Every single time you press the 'Get mail' button...it does get new mail.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

On Fri, Oct 03, 2003 at 02:06:08PM +1000, Michael Wookey wrote:
> Hi,
>
> I've tidied up this patch based upon the feedback received so far and
> obtained some benchmarks. The "region check" only occurs in the following
> cases:

It applied cleanly, and works great!  Thanks.

On Fri, Oct 03, 2003 at 04:00:14PM +0200, Bram Moolenaar wrote:
>
> Michael Wookey wrote:
> Is the gain in speed for avoiding the check for overlaps enough to
> justify adding these tricks?  It's very bad to add code that may have
> obscure problems that happen in rare situation

The slow redraw has been noticeable enough for coworkers to avoid using
gvim.  On my slow laptop machine, it is *very* noticeable.  This is a
great patch IMO.

On 3 Oct 2003 at 16:00, Bram Moolenaar wrote:

> Michael Wookey wrote:
>
> > I've tidied up this patch based upon the feedback received so far and
> > obtained some benchmarks. The "region check" only occurs in the
> > following cases:
> >
> >   - after the window is resized
> >   - after the window is moved
> >   - after the window obtains focus
> >
> > These handle the cases where there may be an "always on top" window
> > overlapping gvim as the gvim window may have been resized (but now
> > under another window), or moved (and may be offscreen/under another
> > window). The calculation is always done when gvim gets focus incase
> > there may be other "on top" windows obscuring the main gvim window.
>
> It looks like this doesn't take care of another program opening a popup
> window (splash window) without a focus change.  This may happen when Vim
> is busy with a slow script, or another program is popping up a window
> without obtaining focus.

I wondered that, things like the little popups from system tray
utilities was the case I thought off.  I tried it, plus having the
start bar appear (I tend to have it on auto-hide) over the scrolling
region, and I saw no problems.  Do you have a case of this happening
and causing problems?

I am not a Windows GUI programmer by a long shot, but perhaps the
window Z-order can be picked up at the beginning and tested each time
around to see if it has changed (i.e. something has appeared above it
and is overlapping)?  Certainly quicker to check one window rather
than many others.

> Is the gain in speed for avoiding the check for overlaps enough to
> justify adding these tricks?  It's very bad to add code that may have
> obscure problems that happen in rare situations.

It would seem so - the intersecting window test seemed relatively
heavy weight so that an optimization would be worth it.  A simple
solution could be YAO, or add to 'guioptions' to enable optimised
scrolling and document it may need a CTRL-L to recover from damage
due to pop-up windows during a scroll.

Mike
--
The Difficulty is not with new ideas, but in escaping the old ones.

Vim shouldn't change the timestamp of the directory in
which the file it's saving resides. Vim is the only
editor to do so. It's really annoyance when you modify
a file but your directory timestamp is also changed.
No, I'm not talking about swap file or backup file.
I'm talking about the directory NNNN that Vim creates
before saving the file and deletes just after the file
is saved. So "set backupdir" or "set directory"
wouldn't help. Please introduce "set secretdir" for
that NNN directory or just create it in the path of
"set backupdir" or "set directory". Many thanks.


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Mike Williams wrote:

> > Michael Wookey wrote:
> >
> > > I've tidied up this patch based upon the feedback received so far and
> > > obtained some benchmarks. The "region check" only occurs in the
> > > following cases:
> > >
> > >   - after the window is resized
> > >   - after the window is moved
> > >   - after the window obtains focus
> > >
> > > These handle the cases where there may be an "always on top" window
> > > overlapping gvim as the gvim window may have been resized (but now
> > > under another window), or moved (and may be offscreen/under another
> > > window). The calculation is always done when gvim gets focus incase
> > > there may be other "on top" windows obscuring the main gvim window.
> >
> > It looks like this doesn't take care of another program opening a popup
> > window (splash window) without a focus change.  This may happen when Vim
> > is busy with a slow script, or another program is popping up a window
> > without obtaining focus.
>
> I wondered that, things like the little popups from system tray
> utilities was the case I thought off.  I tried it, plus having the
> start bar appear (I tend to have it on auto-hide) over the scrolling
> region, and I saw no problems.  Do you have a case of this happening
> and causing problems?

You never know when Microsoft changes something that breaks your
program.  It's better to stick to the documented behavior than base your
coding on experimentation.  Well, you probably need to use both to stay
on the safe side.

> I am not a Windows GUI programmer by a long shot, but perhaps the
> window Z-order can be picked up at the beginning and tested each time
> around to see if it has changed (i.e. something has appeared above it
> and is overlapping)?  Certainly quicker to check one window rather
> than many others.

I would think that in most situations Vim is the toplevel window, thus
the check finishes very quickly.  I don't see a good reason to try to
optimize this check for overlapping windows.

> > Is the gain in speed for avoiding the check for overlaps enough to
> > justify adding these tricks?  It's very bad to add code that may have
> > obscure problems that happen in rare situations.
>
> It would seem so - the intersecting window test seemed relatively
> heavy weight so that an optimization would be worth it.  A simple
> solution could be YAO, or add to 'guioptions' to enable optimised
> scrolling and document it may need a CTRL-L to recover from damage
> due to pop-up windows during a scroll.

Oh No!  NOT another option!

--
How many light bulbs does it take to change a person?

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Ron Aaron wrote:

> On Fri, Oct 03, 2003 at 04:00:14PM +0200, Bram Moolenaar wrote:
> >
> > Michael Wookey wrote:
> > Is the gain in speed for avoiding the check for overlaps enough to
> > justify adding these tricks?  It's very bad to add code that may have
> > obscure problems that happen in rare situation
>
> The slow redraw has been noticeable enough for coworkers to avoid using
> gvim.  On my slow laptop machine, it is *very* noticeable.  This is a
> great patch IMO.

I wasn't commenting on the part that avoids the SW_INVALIDATE when it
isn't needed.  I was wondering if the check for overlapping windows can
be skipped.  I suspect there are situations where this implementation
doesn't notice that a window is on top of Vim and scrolling will be
screwed up (you would see parts of the overlapping window instead of the
original text).

--
From "know your smileys":
  !-| I-am-a-Cylon-Centurian-with-one-red-eye-bouncing-back-and-forth

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Roboco Sanchez wrote:

> Vim shouldn't change the timestamp of the directory in
> which the file it's saving resides. Vim is the only
> editor to do so. It's really annoyance when you modify
> a file but your directory timestamp is also changed.
> No, I'm not talking about swap file or backup file.
> I'm talking about the directory NNNN that Vim creates
> before saving the file and deletes just after the file
> is saved. So "set backupdir" or "set directory"
> wouldn't help. Please introduce "set secretdir" for
> that NNN directory or just create it in the path of
> "set backupdir" or "set directory". Many thanks.

I have no idea what you are talking about.  Vim doesn't create a
directory next to the file it writes.

Anyway, if you write a file it's not strange that the directory it
contains is changed.  You can avoid this by letting Vim overwrite the
original file (reset 'backup' and 'writebackup') but you risk loosing
your work if the power drops that moment.  On Unix the directory is
still changed anyway, since the timestamp of the file is updated.

--
From "know your smileys":
  :-)-O Smiling doctor with stethoscope

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

On Friday, October 3, 2003 Bram Moolenaar wrote:

> Michael Geddes wrote:

>> Er no. Renaming doesn't work with win32, sorry David.
>>
>> This question has been asked before, and the answer was something along
>> the lines that there a bunch of potentially different versions of
>> vim.exe that could sensibly be deployed, and that Bram was unable to
>> choose any one of them (yes?).

> On Unix a program always starts with just
> stdin/stdout/stderr and has to
> open a connection to the X server to start using windows.  On MS-Windows
> a program is either a "DOS" program or a "Windows" program.  I don't
> think it is possible, or at least it is not easy, to have a program that
> starts in a DOS console and starts opening windows after that.  Thus you
> can't make Vim run in a console or open windows by adding a command line
> option.

> It would be possible to make a wrapper that starts vim.exe or gvim.exe
> depending on an argument, but you still need the two executables, thus
> it doesn't make much sense.

As a general rule I agree that the wrapper doesn't make sense.
OTOH, I do think that a package should be provided that
includes all three versions (GUI, Vim-32, Vim-16); executables
could be called gvim.exe, vim32.exe, vim16.exe (You could then
make a wrapper vim.exe that chooses the appropriate version).

Also, technicall speaking under DOS/Windows you can put more
than one version in the same .exe; *most* of the time, the DOS
part is just a stub that says "Hey man, you need Windows to run
this program!", but nobody prevents you from using a
"different" stub, like for example the 16-bit console version.
So you could create a single vim.exe containing both the 16-bit
and the 32-bit console version.

--
Giuseppe "Oblomov" Bilotta

Ok, I have a problem that has (seemingly randomly) appeared
again.

When I am typing, some spots in a file will decide
everything I type is going to try and create a digraph.
Every letter has to be typed twice to get it out, except for
double-letter digraphs such as 'ss' which gives me the ß
character.

Needless to say, this makes doing anything VERY difficult!

Here are a few details about the environment:

VIM: 6.2 (unpatched)
OS: Solaris 8
Arch: Sparc
Window Manager: fvwm2
Login: Connected remotely using Exceed from a Win2k computer
Compiler: gcc 3.1
Configure options: --with-features=big

The lab machine gvim is running on is on the same subnet,
though there are two switches between me and that machine.

Any ideas on how to fix this problem?

--David

On 2003-10-03, Bram Moolenaar <Bram@...> wrote:
> Roboco Sanchez wrote:
>
> > Vim shouldn't change the timestamp of the directory in
> > which the file it's saving resides. Vim is the only
> > editor to do so. It's really annoyance when you modify
> > a file but your directory timestamp is also changed.
> > No, I'm not talking about swap file or backup file.
> > I'm talking about the directory NNNN that Vim creates
> > before saving the file and deletes just after the file
> > is saved. So "set backupdir" or "set directory"
> > wouldn't help. Please introduce "set secretdir" for
> > that NNN directory or just create it in the path of
> > "set backupdir" or "set directory". Many thanks.
>
> I have no idea what you are talking about.  Vim doesn't create a
> directory next to the file it writes.
>
> Anyway, if you write a file it's not strange that the directory it
> contains is changed.  You can avoid this by letting Vim overwrite the
> original file (reset 'backup' and 'writebackup') but you risk loosing
> your work if the power drops that moment.  On Unix the directory is
> still changed anyway, since the timestamp of the file is updated.

The file's timestamp is kept in the inode, not in the directory, so
changing a file's contents should not affect the directory.

If I have

     set nobackup
     set nowritebackup
     set noswapfile

in my ~/.vimrc, and I use vim to modify a file, the directory time
stamp is not changed.  (This is using vim-6.2 on HP-UX 10.20.)

I have no idea what this "NNN directory" could be, either.  Some
plugin?

Gary

--
Gary Johnson                 | Agilent Technologies
garyjohn@...     | Wireless Division
                              | Spokane, Washington, USA

> As a general rule I agree that the wrapper doesn't make sense.
> OTOH, I do think that a package should be provided that
> includes all three versions (GUI, Vim-32, Vim-16); executables
> could be called gvim.exe, vim32.exe, vim16.exe (You could then
> make a wrapper vim.exe that chooses the appropriate version).

If your system can run "vim32", why do you want "vim16"?

> Also, technicall speaking under DOS/Windows you can put more
> than one version in the same .exe; *most* of the time, the DOS
> part is just a stub that says "Hey man, you need Windows to run
> this program!", but nobody prevents you from using a
> "different" stub, like for example the 16-bit console version.
> So you could create a single vim.exe containing both the 16-bit
> and the 32-bit console version.

This is very easy.  Assume that you've already built the DOS version of
vim.exe, and renamed it "vim16.exe", and put it in your object file
directory.  When you are linking "vim.exe" (the 32-bit Windows console
version), add "/STUB:vim16.exe" to the LINK command line and the linker
will do the rest.  The only downside is that (obviously) the file would
be somewhat larger...

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!