Hi Tim, 05.02.2015 01:27, Tim E. Real wrote: > On February 4, 2015 10:33:56 AM Andrew Deryabin wrote: >> Hi guys! >> >> I want to know your opinion - watch this video: >> >> http://youtu.be/g_QhDZbFTUk >> >> I made some modifications to meter widget so the transition from big to >> low values is interpolated instead of using discrete values instantly. >> On the left side - old behavior, on the right - new. >> 2 different instances of MusE are synced to jack transport and are >> playing the same song. >> >> If you accept it, I'll make a commit... > Haven't checked it yet, but as long as there is no speed hit, it's OK. > > A lot of effort went into making the meters fast because when > you have dozens of them going at once in the mixer(s), any > slow drawing really causes a big speed hit. > You can see it right away - as you bring more of the active meters > into view, any slow drawing causes them to really chunk along. > Although, you might not see it now 'cause they're quite fast. Comparable to even MVerb or any other plugin on my system 20+ meters eat < 1% of Mverb plugin cpu usage.
I performed some profiling tests. The setup was the same as in video file. About the code: new algorithm uses 3-4x more redraw calls than old (average value). Now about cpu usage: (tested with oprofile) old behavior: 1199 0.0284 libmuse_widgets.so MusEGui::Meter::setVal(double, double, bool) 891 0.0211 libmuse_widgets.so MusEGui::Meter::metaObject() const 289 0.0068 libmuse_widgets.so MusEGui::Meter::paintEvent(QPaintEvent*) 258 0.0061 libmuse_widgets.so MusEGui::Meter::drawVU(QPainter&, QRect const&, QPainterPath const&, int) new behavior: 683 0.0247 libmuse_widgets.so MusEGui::Meter::metaObject() const 568 0.0206 libmuse_widgets.so MusEGui::Meter::updateTargetMeterValue() 517 0.0187 libmuse_widgets.so MusEGui::Meter::paintEvent(QPaintEvent*) 506 0.0183 libmuse_widgets.so MusEGui::Meter::setVal(double, double, bool) 377 0.0137 libmuse_widgets.so MusEGui::Meter::drawVU(QPainter&, QRect const&, QPainterPath const&, int setVal function now takes less cpu than before - it only sets desired values and starts timer (if not already started). All further work is performed in updateTargetMeterValue(). Now paintEvent() eats 0.0187/0.0068 = 2.75 times more cpu than before. Compared to 3-4x more redraw calls, 2.75 multiplier of cpu usage is a rather good. That's, I think because of less drawing operations when value tends to zero. Regards, Andrew > > Tim. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Lmuse-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmuse-developer -- Regards, Andrew ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
