Re: [Denemo-devel] Speed of Cursor Animation (was Re: Palettes)

[Richard Shann]

On Mon, 2013-10-14 at 18:13 +0100, Richard Shann wrote:
> I have just tested Denemo on an Asus Eee with
> a dual core Intel Atom 1.33 GHz cpu running Windows Vista Home.
Something else I tested - slowing down the playback with a 44100
stereo .wav file loaded (via Open->Open Source Audio) - and much to my
surprise this also worked ok.
Perhaps you could test this too.

Richard


> 
> It works fine as you go between Home and End with fast cursor animation.
> I think there is something seriously amiss with your set up, Bric. It
> simply shouldn't be possible for the cursor animation to slow things up,
> as you describe since the re-draw requests are queued so that if the
> machine is so busy that by the time the draw happens it is too late then
> all that will result is that the steps of the animation will be skipped
> (because it looks at the time and decides which step it should draw).
> (It doesn't know that there are steps, just knows what it should draw at
> a given number of milliseconds after the start, too late and it should
> just draw the final result).
> 
> Note, that this is purely a drawing artifact - if you start typing in
> notes they should go in correctly while the animation is taking place;
> not a practical benefit of course, but worth testing that this does
> happen. On the face of it, this seems like some bug in the version of
> GTK, I wonder if you could try the binary (you can install that as a
> user in your home directory).
> 
> Richard
> 
> On Mon, 2013-10-14 at 05:14 -0400, Bric wrote:
> > On 10/14/2013 03:28 AM, Richard Shann wrote:
> > > On Sun, 2013-10-13 at 13:48 -0400, Bric wrote:
> > >>> BTW, Can you confirm that turning off the cursor highlighting
> > >> doesn't
> > >>> speed anything up? I am interested in the speed of operation thing,
> > >>> which I can't easily test myself. It might be useful to turn off the
> > >>> Undo/Redo to see if that affects it. In ancient versions there was a
> > >> lot
> > >>> of recalculating the positions of things in the bar, so, if anything
> > >>> modern versions should be quicker.
> > >> Oh my god! Y-y-yes!  You betcha, it speeds things up (why haven't i
> > >> done
> > >> this sooner?)
> > >>
> > >> The easy test for me is going back and forth between [Home] and [End]
> > >> positions.  Also, cursoring forward/back with "Ctrl+[Left/Right]"
> > >> With
> > >> the cursor animated ("highlighted"), I wait several seconds with
> > >> these
> > >> operations, with the staff scrolling sideways in front of me.  With
> > >> the
> > >> cursor highlighting turned off, the (non!)scrolling is instant! I
> > >> love
> > >> it! (it's truly a relief... apologies to the animators... it's a
> > >> clever
> > >> and beautiful idea but it's been slowing me down, at least on this
> > >> system — Intel(R) Core 2 Duo CPU T5800  @ 2.00GHz, Ubuntu Maverick)
> > > Hmm, I wonder what can be going on here - I'll try to test out on a slow
> > > windows box that I can get to later today. Otherwise I'll have to ask
> > > you to point a camera at the screen and video it!
> > > When you say several seconds, during those several seconds is the
> > > transition effect taking place, e.g. the music sliding sideways, the
> > > cursor rectangle growing smaller? Or is there some delay and then the
> > > transition effect happens in about 0.2 seconds? Well, I'll see if I can
> > > reproduce this for myself.
> > 
> > Yes, the transition effect is happening, when the feature is turned on — 
> > the measures scrolling left or right.  And that's what seems to eat up 
> > the time, mostly, as well as the cursor rectangle growing smaller, just 
> > as you describe.  But that's slow and choppy for me (or at least, slow 
> > compared to what I assume is the original target speed).
> > 
> > And, you're right — it would need to be a video recording completely 
> > external to the system; otherwise, the video capture software would 
> > probably affect the sluggishness  (I guess I'll try both methods)
> > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel