Re: vim-gtk1/gtk2 scrollbar bug?
- On Son, 2003-04-06 at 13:59, Bram Moolenaar wrote:
> Daniel Elstner wrote:No it isn't. I said "cursor flicker" -- the cursor moves to the end of
> > This function seems to be called quite a lot even if no scrolling is
> > going on, causing quite noticable cursor flicker (mostly in select mode
> > or when inserting new text within comments). I attached an improved
> > patch that avoids calling gui_mch_set_scrollbar_thumb() if sb->value
> > hasn't changed.
> That you see flicker is a GTK problem, it should be able to draw in such
> a way that it doesn't flicker when the thumb didn't move.
the line for a brief moment. This does still happen even if avoiding
unnecessary scrollbar updates, but it's much less visible.
(Frankly, the whole Vim GUI code is broken by design from a GTK+ point
of view. Doing any drawing outside the "expose_event" handler is
basically unsupported, but Vim does it all the time. The ugly hacks all
over the place to circumvent the GTK+ main loop aren't kosher either;
sometimes I wonder why it works at all. It's no use to accuse GTK+ for
not being grateful for Vim's misdeeds.)
> Anyway, wePlease don't make it more hackish than it already is...
> better optimize the code a bit and only call the GUI function when the
> value changed.
> I now checked Motif and it has the same problem. Perhaps the only GUI
> that is different is Athena, because it uses a custom scrollbar.
> Another solution would be to store the new value in the scrollbar, but
> not call the GUI function to update it. Might work for a few GUIs...
> This is what I have now:[...]
Tested, works fine.