On Wed, Jan 7, 2015 at 9:05 PM, Lubomir I. Ivanov <[email protected]> wrote:
> On 8 January 2015 at 00:10, Tomaz Canabrava <[email protected]> wrote: > > > > > > On Wed, Jan 7, 2015 at 7:10 PM, Lubomir I. Ivanov <[email protected]> > > 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 > -- >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
