Re: Patch - Win32 GVIM (SW_INVALIDATE)
- On 3 Oct 2003 at 16:00, Bram Moolenaar wrote:
> Michael Wookey wrote:I wondered that, things like the little popups from system tray
> > 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.
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 toIt would seem so - the intersecting window test seemed relatively
> justify adding these tricks? It's very bad to add code that may have
> obscure problems that happen in rare situations.
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.
The Difficulty is not with new ideas, but in escaping the old ones.
- 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.