On 15 January 2015 at 13:34, Tomaz Canabrava <[email protected]> wrote: > > > On Thu, Jan 15, 2015 at 9:15 AM, Lubomir I. Ivanov <[email protected]> > wrote: >> >> On 15 January 2015 at 02:56, Tomaz Canabrava <[email protected]> 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 -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
