On Friday 25 Feb 2005 23:57, Guillaume Laurent wrote: > what difference > does it make that I'd convert the timeT to x coord in the View as you > suggest, or in the Model as I currently do ?
I gave an example of where it makes a difference: drawing repeating trails. For these, what you currently do is store the width of a repeat in graphical coordinates (converting in the Model) and then in the View you draw rectangles at multiples of that repeat width. This results in incremental rounding errors unless the repeat width is exactly expressible in graphical coordinates: as you scroll right, the repeat rectangles will gradually drift away from the bar lines. This is easy to test, in either HEAD or in 1.0 (prior to my fix yesterday on the 1.0 branch). Just set to the tempo to something that isn't a nice round number, then create a one-bar repeating segment and scroll right to see the obvious mounting inaccuracy. You can minimise the effects of this by storing the repeat width as a float or double, but you're bound to still end up with some rounding error, which may become significant if you then do something like converting back from graphical to time coordinates when someone double-clicks on a repeat. It's a very basic problem -- instead of using a value that we already know exactly (the position of any given repeat), you're recalculating it approximately. That's a silly thing to do. > (except that it breaks > the clean seperation I've tried to maintain between the view being > strictly x,y-based and the model being all timeT,trackId-based). If you're going to maintain that separation, then you need to be doing things like passing the exact positions of the individual visible repeat boundaries from the Model to the View in display x coordinates, not just passing a value that the View can use to approximate them. As it is, your separation is a fiction -- you're doing something in the View that really needs to be time-based (calculating positions of repeats), but because you don't have the time information, you have to approximate using display information. Either move that calculation into the Model somehow (maybe by adding the repeat rectangles to your calculated rectangle list), or give up the pretence and bring the time data into the View. This may also be relevant when doing things like previews, depending on how you're thinking of handling them. In 1.0, for example, an audio preview behaves wrongly if the tempo changes in the middle of the audio clip. That's because we take the audio preview data in real-time units and distribute them evenly across the width of the segment item. If you pass the unmodified audio preview data from your Model to the View and render it in the View without access to time information, you'll have the same problem and it'll be quite hard to fix. (Actually, the fix for that may be better placed elsewhere, like the audio preview helper thread -- which has all the time in the world to calculate the preview in proper display coordinates. But it's the same class of problem and we've got to be aware of it.) By the way -- I should probably say that I do think the CompositionView design is a big improvement, regardless of the details I'm arguing about. Chris ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
