PDA

View Full Version : SqueezeboxG - scrolling optimisations



Triode
2005-02-26, 11:01
Hi,

For a while I've been meaning to look at the scrolling text mechanism for graphical squeezeboxes as on my poor P3 500MHz server it
takes noticable cpu load. Anyway I've come up with the attached with covers two areas:
- further optimisations to the scrolling and rendering code (in addition to Dean's original ones)
- ability to alter the number of pixels scrolled each interval via the web setup screen. On powerful servers and good networks this
seems to allow much smoother scrolling (in the limit one pixel at a time)

If interested - please give it a try...

The optimisations trade off a bit more memory to attempt to render as few times as possible and also attempt to avoid walking bitmap
arrays unless absolutely necessary - doing this has made the code less elegant, but faster - I leave up to the reader as to whether
this is better! [of course the easy answer is to buy a new server....]

Adrian

kdf
2005-02-26, 14:01
nice work. large text, single pixel at 0.01 scrollrate and the cpu usage is
under 2%. a bit higher when playing. The scrolling does seem to stutter now
and again (more on large than small), but I think that's a fair trade. There
are other tasks that have priority over scrolling text.

-kdf

Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> Hi,
>
> For a while I've been meaning to look at the scrolling text mechanism for
> graphical squeezeboxes as on my poor P3 500MHz server it
> takes noticable cpu load. Anyway I've come up with the attached with covers
> two areas:
> - further optimisations to the scrolling and rendering code (in addition to
> Dean's original ones)
> - ability to alter the number of pixels scrolled each interval via the web
> setup screen. On powerful servers and good networks this
> seems to allow much smoother scrolling (in the limit one pixel at a time)
>
> If interested - please give it a try...
>
> The optimisations trade off a bit more memory to attempt to render as few
> times as possible and also attempt to avoid walking bitmap
> arrays unless absolutely necessary - doing this has made the code less
> elegant, but faster - I leave up to the reader as to whether
> this is better! [of course the easy answer is to buy a new server....]
>
> Adrian
>

Triode
2005-02-27, 08:53
Glad you like it.

I think the jitter is an artifact of the current multitasking model rather than simply the priority. 0.01 is a timer firing once
every 10 ms, which is much faster than the expectation for background tasks to complete in?

It would be quite easy to add another class of high priority timers which always get serviced first (or possibly get serviced at the
expense of normal timers in a pass of the idle loop). But I suspect this is looking in the wrong place?

As a sanity check if you change the threshold in watchDog() to 0.01 (rather than 0.5) and turn on --d_perf, I assume the tasks
taking too long occur at the same time as the stutter??

BTW - I think an extra line is needed in slimserver.pl - idle()
" if ($::d_perf) { $to = watchDog(); }" is needed before the call to: Slim::Web::HTTP::idle();

Otherwise the time spent in the select statement is recorded as in http::idle with perf enabled.

Any chance you could check this in if you agree? (or whoever owns this code)

Adrian


----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Saturday, February 26, 2005 9:01 PM
Subject: Re: [Developers] SqueezeboxG - scrolling optimisations


> nice work. large text, single pixel at 0.01 scrollrate and the cpu usage is
> under 2%. a bit higher when playing. The scrolling does seem to stutter now
> and again (more on large than small), but I think that's a fair trade. There
> are other tasks that have priority over scrolling text.
>
> -kdf
>
> Quoting Triode <triode1 (AT) btinternet (DOT) com>:
>
>> Hi,
>>
>> For a while I've been meaning to look at the scrolling text mechanism for
>> graphical squeezeboxes as on my poor P3 500MHz server it
>> takes noticable cpu load. Anyway I've come up with the attached with covers
>> two areas:
>> - further optimisations to the scrolling and rendering code (in addition to
>> Dean's original ones)
>> - ability to alter the number of pixels scrolled each interval via the web
>> setup screen. On powerful servers and good networks this
>> seems to allow much smoother scrolling (in the limit one pixel at a time)
>>
>> If interested - please give it a try...
>>
>> The optimisations trade off a bit more memory to attempt to render as few
>> times as possible and also attempt to avoid walking bitmap
>> arrays unless absolutely necessary - doing this has made the code less
>> elegant, but faster - I leave up to the reader as to whether
>> this is better! [of course the easy answer is to buy a new server....]
>>
>> Adrian
>>
>
>
>
>

Peter Speck
2005-02-27, 13:38
On 27/2-2005, at 16:53, Triode wrote:

> I think the jitter is an artifact of the current multitasking model
> rather than simply the priority. 0.01 is a timer firing once every 10
> ms, which is much faster than the expectation for background tasks to
> complete in?

It too is a very low scheduling latency for any non-realtime server
(such as unix and Windows) doing anything else than running SlimServer.

I would suggest adding animation capabilities to the firmware. I don't
think we can get non-stuttering smooth scrolling without firmware
support.

However, the support doesn't need to be extensive. The simplest
solution as I see it, would be to add a
server->client command:
"wait" u32 # command
jiffies u32
This command makes the SB wait with processing further commands until
the time specified by jiffies has arived. It will still continue to
play music, of course.

This will enable the server to send a series of grfd, wait, grfd, wait,
grfd, wait, grfd, wait commands to the SB without having to send them
at exactly the proper time.

An added bonus would be an "stat" server->client command which could be
put at the end of such a series of commands. It will simple make the
client send a "STAT" response, so the server knows the client is ready
again.

Much more extensive support would be nice, but as a first start (as
doing firmware is hard), I think the barebones "wait" solution might be
a good shot.
----
- Peter Speck

kdf
2005-02-27, 14:18
Quoting Peter Speck <speck (AT) vitality (DOT) dk>:


> I would suggest adding animation capabilities to the firmware. I don't
> think we can get non-stuttering smooth scrolling without firmware
> support.

lets assume firmware is not an option for the moment, since there is only one
person who is able to do anything with firmware on squeezebox. The problem
with moving one pixel at a time, is that it is a lot of cycles to move at a
readable speed. It wasn't so much a complaint, as a simple note. Its still an
improvement in my books, given the limits of the hardware/firmware.

of course, I will have to leave this up to Dean. I have stayed away from
animations since the G-display came long.

-kdf

dean
2005-02-27, 18:30
I think client-side animations are a great idea, but given the
limitations in CPU and memory on Squeezebox, it's not likely to happen
soon.

Triode's patch is most welcome...

-dean

On Feb 27, 2005, at 1:18 PM, kdf wrote:

> Quoting Peter Speck <speck (AT) vitality (DOT) dk>:
>
>
>> I would suggest adding animation capabilities to the firmware. I don't
>> think we can get non-stuttering smooth scrolling without firmware
>> support.
>
> lets assume firmware is not an option for the moment, since there is
> only one
> person who is able to do anything with firmware on squeezebox. The
> problem
> with moving one pixel at a time, is that it is a lot of cycles to move
> at a
> readable speed. It wasn't so much a complaint, as a simple note. Its
> still an
> improvement in my books, given the limits of the hardware/firmware.
>
> of course, I will have to leave this up to Dean. I have stayed away
> from
> animations since the G-display came long.
>
> -kdf
>

kdf
2005-02-27, 19:17
Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> I think client-side animations are a great idea, but given the
> limitations in CPU and memory on Squeezebox, it's not likely to happen
> soon.
>
> Triode's patch is most welcome...
>

I hear that :)

I'll merge it in.
-kdf

dean
2005-02-27, 23:06
Whoops, I didn't mean for you to do that yet. I'm getting Triode set
up with the SB2 branch so he can take a look at the changes and do the
merge.

Probably ok, let's see what he says.

On Feb 27, 2005, at 6:17 PM, kdf wrote:

> Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:
>
>> I think client-side animations are a great idea, but given the
>> limitations in CPU and memory on Squeezebox, it's not likely to happen
>> soon.
>>
>> Triode's patch is most welcome...
>>
>
> I hear that :)
>
> I'll merge it in.
> -kdf
>

Peter Speck
2005-02-28, 01:08
On 28/2-2005, at 2:30, dean blackketter wrote:

> I think client-side animations are a great idea, but given the
> limitations in CPU and memory on Squeezebox, it's not likely to happen
> soon.

But the "wait" command doesn't tax the SB like real animation commands.
It's not much more than just an extra variable and an if-test. Is that
really out of the bounds of what SlimDevices are able to do with the
SB?

----
- Peter Speck