On Monday 19 Dec 2005 22:08, Guillaume Laurent wrote: > On Monday 19 December 2005 21:25, Chris Cannam wrote: > > More to the point though I'm not very happy with the rather random > > approach here. > > It's not random, but I don't want to go disrupting everything at this > stage.
Just that I think there's been too much disruption already -- I don't think the artifacts buffer refresh stuff should have been messed with at all at this stage (unless there's something actually wrong with it, and I haven't seen any evidence of that yet). The crucial, trickiest bit to get right is the contents of checkScrollAndRefreshDrawBuffer, and I don't think that's right at all in HEAD. > > -- There's no benefit in recording changes outside the visible > > area, as they will be updated completely when scrolled to anyway. > > Indeed, but these changes won't be drawn either, they are filtered > out by getRectanglesIn(). My very long audio segments test didn't work correctly until I started clipping the refresh area at the window edges, though. Long audio segments (over 32767 pixels wide, I dare say) weren't being updated on selection/deselection etc. I never got as far as finding out why, I just noticed that a very large refresh rectangle was being passed around, thought "that seems rather inefficient" and clipped it. Remove the QRect area "&" with the visible area from CompositionView::slotSegmentsDrawBufferNeedsRefresh(QRect) and try a very long audio segment if you want to try to find out why; I haven't the energy. > > -- We should leave the artifact buffer well alone unless we find > > bugs or serious inefficiencies in it (to simplify our changes, > > which are complicated enough to get right already). > > not sure what you mean here. I mean that the point at which I started getting worried about all this was the point where you started messing about applying refresh rectangles to the artifacts buffer. The artifacts buffer has the advantage of being fairly simple: leave well alone, unless you find an actual problem with it. We shouldn't be going out of our way to fix problems that we don't have, at this point. > I couldn't spot any problems actually, except for the midi preview > not being there until the first even is recorded, as you noted. I wasted some time on that one this evening, but never got it sorted. The problem of course is that the MIDI record segment isn't placed in the composition until the first event is recorded (unlike the audio record segments which don't have this problem -- for MIDI we try to make it easy to discard the segment if nothing ends up going into it). I modified the document so as to put the record segment into the composition straight away, but I kept running into hideous crashes when updating after stopping recording without recording any events (so the segment was empty and thus was removed and should have been tidily deleted, but something seemed to be re-adding it -- possibly a local call vs. DCOP call race condition -- and so a subsequent update would crash). And I just didn't have the brainpower. I'll try to send a patch for what I'd done to the list, in case it's obvious what the fix is. > I'd apply it to HEAD with a few reserves, like the renaming back of > slotUpdateSegmentsDrawBuffer() to slotUpdate(). It's not really renaming _back_ -- I just never used that update, I backed out your last few commits and started from earlier on at a point where I was less confused. I should have branched from that earlier point too, but by the time I thought of branching it was a bit too late. So no, I've no problem with that change. > > Note special only-if-recording hack in setPointerPos. > > Yikes, not sure I like the forced repaint, that's usually a cause of > high CPU consumption. Doesn't it work without it ? I have yet to find any other way to force the pointer-position change update and the segment-size change update to come through as two separate paint events rather than one big one. If you can find one, please do. I tried the WPaintClever flag and it didn't seem to help (though if it does help for you, I could try it again just in case). If you remember, in another email on this subject a few days ago I commented that the problem seemed to be two problems -- getting the right paint events, and updating the correctly limited part of the window in response to them. All this work with rectangles is only fixing the latter problem -- the forced repaint is a rather clumsy attempt to fix the former. btw one thing we could do to reduce CPU usage during playback and recording overall without (probably) affecting visual quality noticeably is to change the way we use the timer. At the moment we have the play timer (for updates) set up at the outset to fire every 20ms (actually 23ms). If we instead reset it after each update had finished, to fire 23ms (or whatever) later, we would take the time taken for the update out of the 23ms wait, thus increasing overall sleep time, and avoid stacking up timouts if the update took a relatively long time. Chris ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
