Kicker performance: KIconEffect :: visualActivate( ... );

[Maks Orlovich]

On Wednesday 22 October 2003 07:52 am, Waldo Bastian wrote:
> We have async dcop calls now, so it should be possible to make krun async
> and do the visual effect after activation.

An another option is to make visualActivate asynchronous. I have a prototype 
patch for that at http://mail.rochester.edu/~mo002j/patches/async.diff, but 
it's crude, and I haven't yet made up  my mind on whether to keep the old 
(synchronous) path. At any rate, my measurements of delay are far more 
dramatic than those that were in the original message Waldo forwarded -- I've 
seen visualActivate take as much as 1/3 of a second; could be the matter of 
my kernel since the udelay() resolution is highly system specific. I'd 
appreciate if other people measured this; if anything close to what I have 
seen holds for other people, I think we should definitely do something to 
address this; whether doing the asynchronous run, async visualActivate, or 
simply turning off visual activation by default.

-Maks


> ----------  Forwarded Message  ----------
>
> Subject: KIconEffect :: visualActivate( ... );
> Date: Wednesday 22 October 2003 12:38 pm
> From: Enrico Ros <rosenric at dei.unipd.it>
> To: "W.Bastian" <bastian at kde.org>
> Cc: "E.Ros" <rosenric at dei.unipd.it>, "D.Massarin" <nekkar at libero.it>
>
> We noticed that, when launching an application from the kicker, the
> visualActivate effect is executed *before* effectively launching the app.
> This leads to a time loss (at least 50ms of fastest machines) due to a
> poorly optimized uSleep based graphic routine.
>
> Quick-analysis:
> line 199 @ kdebase/kicker/buttons/servicebutton.cpp:
>  KIconEffect::visualActivate( this, rect() );
>  ..
>  KRun::run( *_service, uriList );
> -> Run is called after running the UGLY graphic effect.
>
> Some considerations:
>
> - after kde 3.2 change the API to implement dynamic asyncronous icon
> effects 'in-places' on click.
>
> - bef 3.2: consider to move the visualActivate call to the end of the
> 'slotExec()' slot but this way the effect will be delayed.
>
> - bef 3.2: consider doing some changes to the activate animation! Seems
> more a graphic corruption than an activation... We changed it from the
> dotted line growing to a filled square (XorROP'ped) growind and shrinking
> (enveloped by a sine function).. more attractive and not cpu consuming.
>
> Thanks and Have a nice day!
>  Dario & Enrico
>
> -------------------------------------------------------