[PUSHED 3-5] idle-callbacks in writer don't end early, so your responsiveness sucks rocks

[Michael Meeks]

On Tue, 2012-04-24 at 12:27 +0100, Caolán McNamara wrote:
> This one has nearly killed me trying to track down because its *so*
> variable, but "unusably slow with large documents"
> https://bugs.freedesktop.org/show_bug.cgi?id=48011

	First - thanks for nearly laying down your life here ! :-) I feel your
pain. This API method, is the bane of the porter's life - if you don't
return the right value for the TIMEOUT mask, the app doesn't even start
for obscure & random reasons. [ I notice you caught this by having the
local timeout-ness checked first ;-]

	For a method called only 24 times in the suite outside of VCL, it is a
walking nightmare. A number of the call-sites eg.

editeng/source/editeng/impedit3.cxx

IMPL_LINK_NOARG(ImpEditEngine, OnlineSpellHdl)
{
    if ( !Application::AnyInput( VCL_INPUT_KEYBOARD ) && GetUpdateMode() && IsFormatted() )
        DoOnlineSpelling();
    else
        aOnlineSpellTimer.Start();

    return 0;
}

	Would be much more efficiently replaced by adding a priority layers to
idle handlers, so we could be sure that low-prio handlers (like
spelling) are underneath higher prio events like keyboard input or
re-painting etc.

> I believe is fixed by
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=658954e8b50fc264428402dc5a95b0d6f690d191
> or at least that's a lot of the problem as far as I can tell, takes away
> a 6 second lag I can reproduce on an i7

	Good; well - at least for gtk2.

> i.e. the idle-callbacks in writer are trying to stop if there's any
> unprocessed keyboard, mouse, paint, etc events and the new AnyInput impl
> doesn't quite cut it.

	That's annoying indeed.

> How about the above ?, return to using the old-school traditional one
> for gtk2. And maybe the proposed gtk3 one is sufficient for gtk3,
> definitely the alternative impl *seems* ok for gtk2 is I enable it
> locally experimentally.

	Really ? I recall reading gdkevents, consulting the mainatiners and
tearing my hair over this when I arrived at that solution - having
decided not to pull and re-push all the events to avoid confusing
some-part-or-other of gtk+ (but hopefully I was mistaken).

	Most happy to have the old-style version for gtk2, and the new thing
looks reasonable enough.

	We should prolly remove all the slow & heavy-lifting addEvent /
subtractEvent / resetEvents code if we do it this way though - there is
no need for that anymore.

	Thanks again for all the digging !

	Cherry-picked to -3-5.

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot