On Monday 19 December 2005 21:25, Chris Cannam wrote:
>
> 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.

It's not random, but I don't want to go disrupting everything at this stage.

>  -- 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

Yes, getting rid of the flag was the obvious next step. As it is it's already 
redundant anyway.

> -- 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.

Agreed.

>  -- 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().

>  -- 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'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.

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'd apply it to HEAD 
with a few reserves, like the renaming back of slotUpdateSegmentsDrawBuffer() 
to slotUpdate(). I prefer to have a clear semantic here.

> 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 ?

-- 
Guillaume.
http://www.telegraph-road.org


-------------------------------------------------------
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

Reply via email to