denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Shann
Subject: [Denemo-devel] Speed of Cursor Animation (was Re: Palettes)
Date: Mon, 14 Oct 2013 18:13:02 +0100

I have just tested Denemo on an Asus Eee with
a dual core Intel Atom 1.33 GHz cpu running Windows Vista Home.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]