bugDenemo - Bugs: bug #31557, 0.8.21 view quirks on windows-not...

 
 

bug #31557: 0.8.21 view quirks on windows-not exactly a bug

Submitted by:  None
Submitted on:  Fri 05 Nov 2010 08:59:43 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 07 Nov 2010 12:13:14 AM UTC, comment #5:

This is a highly speculative post.

There is a solution to the bug of the cursor not being visible sometimes and the ragged-right issue, but it could be significant work to implement. That would be to make the view window, or "camera", more independent of the cursor. The whole score would have the illusion of being one huge dynamic image, and the view window would be the portion of this that is seen.

Thinking about this, all one would need to know is 1, which bar the left edge of the view window intersects, which I will call the parent bar, and 2, how far to the right of the bar's beginning this intersection is, call that delta. So if the parent bar is 200 pixels wide and delta is 50, three fourths of the leftmost bar would be visible. The parent bar and enough following bars would be drawn to a buffer, this would be cropped (cutting off a width delta pixels on the left) and displayed to the screen. When delta exceeded the length of the parent bar, this length is subtracted from delta and the parent bar is changed to the next bar, and when delta drops below zero, the parent bar becomes the previous bar and delta becomes the length of that bar + delta (delta being negative). Delta could have a velocity, which would be the velocity of the view window relative to the page, and its acceleration should be just right so that the cursor was kept pretty much right in the middle of the view area. (This would make the camera movement smooth rather than jerky. It would still need to jump if the cursor jumps to the beginning of the score, etc.) One would need to watch out when the camera goes off the left or right edge of the score.

If I had a lot of time, knew gtk, cairo, and denemo's code,(which I don't) I would try to contribute this. But you guys who know these things, what do you think? Is this feasible?

-Dan W

Anonymous
Sat 06 Nov 2010 05:32:03 PM UTC, comment #4:

I still didn't get to try out the new spacing regime, but I have restricted the horizontal scaling trick to compressing lines that are too long, as this is the real bug situation, where you cannot access the end of the measure. In page view on the other hand I let the lines get stretched as well so that they are no longer ragged-right, as this looks better and page view is not generally used for editing but rather for playing back, or looking over the whole score for things.
All in git.

Richard Shann <rshann>
Project Administrator
Sat 06 Nov 2010 10:50:04 AM UTC, comment #3:

"An even bolder change would be that, during playback, the whole score would be rendered once (or once every page width) onto a cairo "canvas" or whatever, and smoothly pan through it as the score progresses. The cursor would be disabled and the current-note highlighting would be in a transparent layer above that one."

Playback is not a read-only process. You can edit notes while doing playback which would be impossible with this method.

-Deleted Account- <steele>
Sat 06 Nov 2010 10:43:34 AM UTC, comment #2:

The drawing of the first system is fixed now in git.
The greyed out measure is by way of a custos, it is repeated at the top of the next page. I looked at trying to not print it, without success:(
(Surprising, that, when I can clearly see where I have switched to grey paint:)
The compressing to fit fixes an important bug, namely depending on the geometry of the window and music content you can find part of a measure inaccessible. You can't see the cursor once it is on those notes, nor see them playing. The stretching to fit is optional, it could be turned off just by putting a ceiling on the scaling of 100%
But I take your point about the view suddenly shifting - I haven't had a chance to do any work with Denemo recently, just fixing bugs...

Richard Shann <rshann>
Project Administrator
Fri 05 Nov 2010 09:03:48 PM UTC, comment #1:

Also, the current drawing method has a quirk in the top staff, upon scrolling left or right, frequently the top staff is drawn out of alignment with the lower staffs for a split second, and then this is corrected.

Also, sometimes the bars to the right side of the page are grey, and sometimes black like everywhere else. Why not draw everything in black? I am not aware of any benefit or significance to the use of grey.
-Dan

Anonymous
Fri 05 Nov 2010 08:59:43 PM UTC, original submission:

Hi, I don't mean to be picky, but the new method of drawing the staffs at different levels of horizontal stretching in order to make it all fit exactly to the right side of the "page", I find to be unattractive and confusing. It doesn't seem right that sometimes the notes are drawn at one width and then you pan right into the next bar and things are suddenly drawn a whole lot thinner, because that next bar has more notes.
Would it be harder to just draw the whole score view page without stretching, with the last visible measure extending beyond the right edge of the view and just cropping whatever doesn't fit? Instead of trying to force a whole number of measures into the view at all times?
This method of drawing is also noticeably slower on windows. I guess because it's putting a more intense workload on cairo?

The less the view changes from one moment to the next, the clearer everything will be, in my opinion. Just my two cents.

An even bolder change would be that, during playback, the whole score would be rendered once (or once every page width) onto a cairo "canvas" or whatever, and smoothly pan through it as the score progresses. The cursor would be disabled and the current-note highlighting would be in a transparent layer above that one. This is coming from someone with no experience or knowledge of cairo, but it seems to me that it should be doable. This could potentially fix some of the windows playback problems, using less cairo calls perhaps, which I would guess are due to cairo, although those problems may have appeared earlier, with the intro of fluidsynth. What do you think?

-Dan W.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by steele (Posted a comment)
  • -unavailable- added by rshann (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 04 Dec 2010 12:20:11 PM UTCsteeleOpen/ClosedOpen=>Closed
    Sat 06 Nov 2010 05:32:03 PM UTCrshannStatusNone=>Fixed

    Back to the top


    Powered by Savane 3.1-cleanup1