Re: Patch - Win32 GVIM (SW_INVALIDATE)
- Yes, gui_mch_insert_lines() should follow the same logic. I had also previously
thought about the optimisations you mention and am currently investigating.
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
>>> /* 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
>>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 ///
- Bram Moolenaar wrote:
> Also check what happens if part of the Vim window extends to below theHelmut's patch works correctly with overlapping windows. It is simply slow. When
> screen and then scroll up the text (with commands, scrollbar or mouse
> scroll wheel).
gvim is obscured by the task bar, it will leave "text trails" while scrolling,
but redraw correctly when scrolling stops.