Kazunobu Kuriyama wrote:
> With the current GTK implementation, the more frequently gui_mch_flush() is
> called, the more slowly the drawing gets done.
>
> This is because of use of gdk_display_sync() in gui_mch_flush().
>
> The function won't return until the X11 server acts on and finishes all the
> requests that were flushed from a client when it was called.
>
> That's why frequent use of gui_mch_flush() results in that slowness,
> contrary to expectations.
>
> Furthermore, the implementation calls gdk_window_process_updates() after
> calling gdk_display_sync().
>
> Basically, gdk_window_process_updates() asks the server to send an expose
> event back to the window for giving it a chance to redraw the contents for
> update.
>
> But just after calling gdk_display_sync(), there is nothing left in the
> request queue for a window to be updated. Hence the call is of no use and
> unnecessary (rather, it could be harmful in performance if a GUI toolkit in
> use synthesizes events for optimization).
>
> The proposed patch attached below is to address these issues.
>
> With the patch, commands such as K in normal mode, :make, :version and
> :highlight get as fast as Athena's, and the slowness that was pointed out
> in GitHub Issue #681 is drastically improved (I'd like to call it
> practically fixed).
>
> That said, in spite of those flaws mentioned above, the current
> implementation has been sitting there for years (perhaps, more than a
> decade. It looks use of a sync function dates back to the very early days
> of GTK GUI...) , and as far as I know, no one has called for or proposed
> improvement so far. They really make me wonder. If someone knows why
> gui_mch_flush() was written in such an unusual way, please enlighten me.
> I'd definitely appreciate it if you would.
>
> As a side note, it looks the patch helps to address Ramel Eshed's GUI
> cursor drawing issue, though the patch itself was not written for that
> purpose (it was actually written as part of a GTK code brush-up).
Thanks. Some of this code may date back to the first GTK
implementation. And since it doesn't cause actual trouble, it may just
have gone unnoticed.
--
ARTHUR: Right! Knights! Forward!
ARTHUR leads a charge toward the castle. Various shots of them battling on,
despite being hit by a variety of farm animals.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
