Loading ...
Sorry, an error occurred while loading the content.

Re: Patch - Win32 GVIM (SW_INVALIDATE)

Expand Messages
  • Mike Williams
    ... 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
    Message 1 of 32 , Oct 3, 2003
    • 0 Attachment
      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.
    • Michael Wookey
      ... Helmut s patch works correctly with overlapping windows. It is simply slow. When gvim is obscured by the task bar, it will leave text trails while
      Message 32 of 32 , Oct 9, 2003
      • 0 Attachment
        Bram Moolenaar wrote:

        > Also check what happens if part of the Vim window extends to below the
        > screen and then scroll up the text (with commands, scrollbar or mouse
        > scroll wheel).

        Helmut's patch works correctly with overlapping windows. It is simply slow. When
        gvim is obscured by the task bar, it will leave "text trails" while scrolling,
        but redraw correctly when scrolling stops.

        cheers
      Your message has been successfully submitted and would be delivered to recipients shortly.