On Monday 12 Dec 2005 15:05, Guillaume Laurent wrote: > The reason the recording audio segment doesn't show is that we > no longer systematically invalidate the segment draw buffer when the > pointer is moved, as it used to be. It's now invalidated only when a > MIDI recording segment receives an event. So we can invalidate it on > pointer move if we're recording, but that makes us redraw a whole lot of > unnecessary stuff (I tried that and from the traces I got, it still > triggers full redraws every time - surprising, as your last changes did > fix that).
There are two ways we can know if something has changed during recording. One is that the pointer has moved (because we need to continually extend the segment block as we record). The other is that something in the recording segment itself has changed. At one point previously we talked about continually updating the end marker time in the recorded segment to provoke an update. I was opposed to that, because that's not what the end marker is supposed to mean (it's intended for reducing the apparent duration of a segment, not extending it, and it's only supposed to exist if the user has overridden the default). However, for audio segments the end marker effectively _does_ change continually during recording, because by default the end marker is inherited from the end time and the end time is calculated from the audio end time (in RealTime units) and that is updated while we record (rosegardenguidoc.cpp:2221). All that's missing is a call to Segment::notifyEndMarkerChange when that value changes on an audio segment, and the canvas will update itself with no further code needed. So, I've committed that. That gives us audio recording segments. It does seem to cost more in CPU than I would have hoped -- do we have more updating than just the single segment that's changed? For MIDI segments, we could still potentially update the end marker while recording, comment it as an internal trick, and remove the end marker when recording finishes. Or we could continually update the rests in the segment as we record (which would also be handy for some future update-a-notation-editor-as-we-record mechanism, such as I implemented about two years ago but never completed satisfactorily) thus updating the actual end time rather than the end marker. Either way is beginning to seem far more satisfactory than wildly refreshing everything available whenever the position pointer moves (during recording anyway). > Yes, it was no longer needed since previews updates are actually > performed on demand, like the rest of the drawing, so manually updating > them was redundant. However this discards indeed the check against > multiple requests. I think this check shouldn't be made by the view but > rather by the audio preview jobs queue itself. The problem with that (architecturally speaking) is that the audio preview thread has no way to know whether two requests are coming from the same place. If two different objects ask for previews on the same segment, we shouldn't refuse to supply one just because the other one came along and asked for the same thing afterwards. The thread actually _does_ throw away duplicate requests that have the same notify callback (i.e. that originate from the same object) -- see audiopreviewthread.cpp:156 (just noticed a really stupid bug there, will commit a fix in a moment -- that's immaterial to this though). But in this case the requests have different notify callbacks because they come from separately constructed AudioPreviewUpdater objects, so the thread has no way to know that one is intended to supersede the other. The composition model is the only thing that actually knows, I think. 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 Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
