From: Orcan O. <oge...@gm...> - 2011-09-16 18:41:47
|
emOn Fri, Sep 16, 2011 at 2:01 PM, Tim E. Real wrote: > On September 16, 2011 10:23:13 am you wrote: >> On Fri, Sep 16, 2011 at 3:25 AM, Tim E. Real wrote: >> > On September 15, 2011 10:50:17 pm you wrote: >> >> On Thu, Sep 15, 2011 at 9:00 PM, Tim E. Real wrote: >> >> > On September 15, 2011 12:23:39 am Orcan Ogetbil wrote: >> >> >> About namespaces... I want to make MusEMidi and MusEAudio namespaces. >> >> >> Is this a reasonable cut? >> >> > >> >> > Why? Are there exposed global variables? If not don't bother. >> >> >> >> I don't think there is a technical restriction that requires us to >> >> have more namespaces. It is more for organizational purpose. Keeping >> >> components separate helps (me at least) find my way around faster. Do >> >> you believe it is too much trouble with little to no gain? >> > >> > Mm, was wondering if it's going a wee bit overboard - where do we stop, >> > when every module has a namespace? >> >> Yes, that was the original goal. >> >> > OTOH Just what elements of audio and midi would gain the namespace? >> > The whole cpp /module/ or just a few class members? >> >> I don't know that yet. Most probably all of the module including >> classes and global functions/variables. >> >> > --- >> > About the meters: I'm afraid it's way too much eye candy. >> > Extensive testing today confirmed that they are having an extreme, >> > profound effect on speed. >> > Especially when there several active mixer strip meters in view. >> > Slows to crawl. A soon as you h-scroll so that only one is in view - boom >> > goes to full speed. >> > When I switch between the old and new meter code the difference is like >> > night and day: From near MusE-1 speed, to a crawl. >> >> That's not good. When I tested it on my machine (not the latest >> technology: AMD Dual Core 3GHz) I did not observe a speed difference. >> I thought maybe they optimized things on the qt side. >> >> > Really I never thought the meters would contribute much time (they never >> > did before) but now I see that the meter code is almost as sensitive >> > and important as the realtime audio thread ! >> > Think about it - heartbeat rate is 20/sec. That means /all/ active meters >> > are constantly being redrawn at that rate. >> > Even worse, in Meter::setVal it calls full update() - causing the whole >> > area to be redrawn /every/ time a new value comes in. >> > Now think of 20 such meters, all active, all redrawing at 20 times/sec... >> > >> > If you bear with me, I am modifying the code so that only /differences/ >> > of values are redrawn (ie Meter gets a previousYVal member), >> > instead of the whole thing. The smaller the next required 'jump' in >> > meter value, the less drawing done. >> > >> > However, it still means sudden large changes can trigger big redraws >> > causing 'fits and stops' type of thing. >> > >> > So I'm afraid for the moment I've had to completely revert the code. >> > (Don't worry - both methods are wrapped in a #if 0 #else type of deal.) >> > It's important because it allows me to see visually the response of the >> > system so I can tweak speed elsewhere, without worrying that the meters >> > are having too much effect (I'm also using printouts of speed.) >> > And speaking of which, PartCanvas was really dragging down drawing >> > too, it would draw the entire length of tracks on /any/ update. >> > That's /before/ it hits the painter clipper, which is bad. >> > >> > I've known about that for a while, but now I've tweaked and optimized it >> > so that /only/ the requested paint rectangle is drawn into. >> > What a difference that made! Again, approaching MusE-1 speed >> > even more now - that is, play the song with 15 wave tracks + and open >> > the mixer and all the meters barely flinch, dancing merrily, versus >> > crawling as it does now. >> > (Well, that's /if/ I disable drawing the actual wave in WaveParts, but >> > that's another issue I'm working on. But it shows you how bad it was, >> > that I disabled that time-intensive wave drawing and it /still/ crawled!) >> > >> > Have not committed yet though. Will see how much speed I can deliver... >> > Tim. >> >> Of course, revert it if we have to. But there are two things that come >> to my mind: >> >> 1- Can we optimize the new fancy meter, and repaint only the relevant >> portions? Would that be fast enough? > As I mentioned above, that's what I'm doing now. Yes they'll be faster, > but the potential is there for several meters to suddenly require a large > jump, causing a brief slowdown, which overall could cause some jerkiness. > > I forgot to mention: About that opaque drawing flag: Yes it IS required. > "Qt normally erases the widget's area before the paintEvent() call. If the > Qt::WA_OpaquePaintEvent widget attribute is set, the widget is responsible > for painting all its pixels with an opaque color." > > Thus, a lot of unnecessary erasing was going on, even before meters are drawn. > This was verified by completely bypassing the paint code: The meters were > /still/ causing somewhat of a slowdown because each call of setVal() calls > full update(), which causes Qt to erase the whole area. That's even /before/ > any meter painting! > Thus you are doing a full erase just to get the little grey areas at the > rounded corners. Not good. I would probably do like I did in PartCanvas > 'hidden events' part-end drawing: Use WA_OpaquePaintEvent, and specifically > draw the little grey corners yourself. > > Let me work on it some more... I'll let you know how it goes. > >> 2- Shall we make the new fancy meter optional through some >> configuration option? > Well, I thought about that, a setting seems a bit much but I'm not > ruling it out. Another option is a quick handy button which turns off all the > meters at will, or at least switches between 'fast drawing' and 'nice > drawing'. > > But I think we should probably have to remove the secondary 'shading' mask > that you have in there, and try to make it more pleasing without that, > somehow. That is, some compromises may be needed... > Hmm, I have an idea: 1- Bottom-most layer: solid red-yellow-green. Not repainted at all unless widget resized 2- Middle layer: the 'shading mask'. Again, not repainted unless widget resized 3- Top layer: semi transparent white. This is the part that will only be repainted on every paintEvent(). We can also make it smarter to paint only the changes since the last paintEvent() without much hassle. The semi transparent white will give the distinction between bright and dark red-yellow-green parts of the meter. This should save us some cpu I think. Orcan |