Patches concerning the speed of mouse-movement over the profile.

[Lubomir I. Ivanov]

On 15 January 2015 at 13:34, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>
>
> On Thu, Jan 15, 2015 at 9:15 AM, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
>>
>> On 15 January 2015 at 02:56, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>> > Lubomir,
>> >
>> > I'v removed almost every allocation that I could find. can you try this
>> > 8
>> > patches and tell me if anything worked to reduce the cpu usage?
>> >
>> >
>> > We can still do some stuff to not remove the animations  ( yup, I like
>> > them
>> > )
>> > like using a square instead of a rounded - rect notification panel.
>> >
>> >
>>
>> unfortunately the patches did not improve the performance much for me
>> - it's still above 20%.
>> but i suggest you skip any more fixes for this ATM, because we have no
>> user complains.
>>
>> the allocations boosted it, but setText(), setPixmap() and the little
>> graph drawing still require high CPU usage.
>
>
> We can also try to move the Profile to OpenGL ( I'v always wanted to learn
> that and that's a pretty damn good excuse. )
>
>>
>>
>> it started to smell to me as a FPU denormal issue, so i tested that
>> because i've noticed the GCC uses FPU instructions for this particular
>> part and the control word flag was unset, but it ain't the cause,
>> unless Qt updates the FPU between calls.
>>
>> -O3 doesn't helps which means that calls to another library are heavy
>> (e.g. Qt).
>>
>> i've also tried using S&H on refresh() to reduce the amounts of calls
>> on power of two intervals and that is the only thing that helps, but
>> reduces the smoothness of the tooltip itself and isn't pretty; a
>> factor of 4 is tolerable but still caps at more than 16% CPU usage.
>>
>> perhaps there are other tricks to try, but i don't have the time.
>
>
> But I do have. :)
> I'll try to do other things:
> - use raster graphics
> - do not use paths
> - do not use translucency
> - try to test the profile in other ways ( OpenGL, perhaps )
>

you could try setting the graphics viewport widget to be QGLWidget as
a start, and see if Qt will optimize anything as is.
but i bet that the ::paint() way of doing it in CPU raster might be
times faster.
a complete OpenGL port will be very time consuming, but obviously this
will be the fastest solution.

i'm not a big Start Trek fan / nerd, but i would like to quote Tuvok
(ST Voyager):
"There are times when perfection hinders efficiency."

;-)

also i think Dirk hinted that you should drop this for good ATM...

lubomir
--