On Monday 19 Dec 2005 14:54, Guillaume Laurent wrote: > On Monday 19 December 2005 13:33, Guillaume Laurent wrote: > > I committed some intermediate stuff at the request of Chris in case > > he could take on from there, so seg canvas has serious update > > problems at the moment. Don't worry about it. > > It should work now, except for a peculiar glitch : when drawing a > selection rect upwards, the rect isn't erased on mouse button release > if no segments were selected.
I dunno about "should work", I found pretty much everything still appeared to be broken (glitching from the selection rectangle, selections not updating properly, recording segments not appearing etc). Mostly this was in cases where the view wasn't scrolled to the canvas origin, so it's probably simple arithmetic going wrong. More to the point though I'm not very happy with the rather random approach here. My theory is that all this messing about with the artifacts buffer code is unnecessary, and is just fixing symptoms of mistakes somewhere earlier along the line. So, I've just committed an alternative fix on a branch called "alternative_hypothesis" based on the following principles: -- We should have a single "area that has been changed" rectangle in the composition view for the segment buffer, and always update and use this (i.e. we don't want to have a separate flag to say something has changed -- the rectangle will be empty if nothing has changed, and will cover the entire visible area if the whole area needs redrawing). This simplifies notification of changes and should make reasoning about the logic of updating easier. -- There's no benefit in recording changes outside the visible area, as they will be updated completely when scrolled to anyway. -- 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). I'd appreciate it if you (specifically Guillaume) can "cvs update -r alternative_hypothesis" and give it a go. It appears to me to get pretty much everything right, including the extent of paint events during recording, but as you know, it's very hard to test everything. There's a whole load of debug output in there of course, which will make it all seem horribly slow. Note special only-if-recording hack in setPointerPos. Next things: -- The MIDI record segment doesn't appear until the first event arrives (but updates smoothly after that). Fix. -- Need one audio preview updater per segment in the composition view, so that preview generation gets cancelled properly when the zoom size etc changes. -- Audio preview generation doesn't start happening until the audio segments are exposed -- we've argued about this before, I maintain my view, we should revert to the former behaviour. -- Audio previews don't take tempo changes into account (bug #whatever, filed in 1643). I have an unexpected hour or so to spare this evening, so I'm going to have a go at one or two of these (probably also on the alternative_hypothesis branch, just because that's where I am, but the commits will be obvious enough if I get around to making any). 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
