the profile is becoming a bit of a cpu hog

Tomaz Canabrava tcanabrava at kde.org
Wed Jan 7 15:12:35 PST 2015


On Wed, Jan 7, 2015 at 9:05 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
wrote:

> On 8 January 2015 at 00:10, Tomaz Canabrava <tcanabrava at kde.org> wrote:
> >
> >
> > On Wed, Jan 7, 2015 at 7:10 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
> > wrote:
> >>
> >> win64, dual core cpu
> >>
> >> general performance drops are observed in both official binaries and
> >> my local debug build.
> >> of course we can wait until *actual* users complain, instead of me.
> >> just a report, as i don't have time to fix any of that ATM. perhaps
> >> later this month...
> >>
> >> i guess this is mostly in Tomaz' field.
> >>
> >> with the recent addition of the mean depth line and text, i've noticed
> >> further increase of cpu usage when hovering the profile. so i've
> >> started "profiling the profile" to see what are the main causes for
> >> the high cpu usage 30%.
> >>
> >> i've realized it's a multitude of things and all contribute a
> >> millisecond or two so that it takes a while to render a frame in the
> >> UI thread. to explain the issue i'm describing, imagine the mean depth
> >> line jumping at 500ms intervals instead of smoothly following the
> >> mouse.
> >
> >
> > Actually, the line doesn't smootly follows the mouse for other reasons,
> > if you see that the tooltipitem is not smootly updating, then there's a
> real
> > issue.
> >
> > the line doesn't smootly follows the mouse because my implementation for
> it
> > is wrong:
> > if the current mouse position is not at a time that exists in the
> plot_info
> > datastructure, it will not
> > generate a line for that position.
> >
> > belive me, I'v tested by creating fake information and it worked.
> >
>
> aha i see, but if i disable the hover code completely it's much
> smoother in a way - no 500ms delays if moving quickly.
>
> >>
> >>
> >> 1) the main hog is ToolTipItem - 20%
> >> perhaps elements can be re-used instead of re-creating them each time
> >> the mouse moves.
> >> also, we can possibly get rid of the animation and store some of the
> >> VALUE / 2 operations in VALUE_D_2 consts. etc...
> >> not sure how well this will work without testing it.
> >
> >
> > The current API of the ToolTipItem supports this, but the main tooltip
> used
> > is a *huge* text, sometimes with more than 16 lines of code
> > we need to clean that - urgently.
> >
>
> i was wondering if it would be possible to populate (allocate) the
> tooltip with the maximum number of data elements ever to be used and
> only show arrange elements when needed and resize the rectangle based
> on that.
>

The tooltip currently contains *one* item, each new line is just a massive
string passed to it.
so, I think most of the work is done by allocating that string, deleting
it, generating the pixmap to be displayed ( rendering of fonts is always a
massive cpu hog, the background of the notification is semitranslucent and
it grows / shrinks.

I wanna a bit of help iwth it.
I wanna a bit of help with moving a node in the Add Dive, most of all.
that's very sluggish and I was unable to solve. =/


>
> addToolTip() / clear() seem to use the most cpu.
>
> >>
> >> 2) those extra 10% are caused by the new
> >> InstantMeanDepthLine::mouseMoved()
> >> as it calculates based on the running average each time instead of
> >> using a lookup table.
> >
> >
> > Hm... can you ( or anyone else ) help me to create a lookup table?
> >
>
> will post again in a moment.
>
> lubomir
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150107/9ef5b78f/attachment-0001.html>


More information about the subsurface mailing list