On 8 January 2015 at 01:12, Tomaz Canabrava <[email protected]> wrote: > > > 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.
hmm, it doesn't seem that much text. > 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. > my point was that perhaps we can try QGraphicsPixmapItem->setPixmap() and QGraphicsSimpleTextItem->setText() instead of recreating the items each time. the text item seems the slowest. > 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. =/ > there are other sluggish parts, indeed - even the main menu for some reason. will see when i will get more free time. lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
