Optimise CMobblerStatusControl::Draw()

[GoogleCodeExporter]

Since switching from the old 0.2.4 version to 0.3.1 I noticed that the
music breaks up a little. Nothing serious, just minor pauses in the music
less than 1/10th of a second that produce very annoying effects on my N95.

I propose to fix this problem by looking into the processor usage using
song playback.

Original issue reported on code.google.com by pbextreme@gmail.com on 17 Dec 2008 at 7:26

[GoogleCodeExporter]

There was a problem with the scrolling marquee which was accidentally given high
priority.  For me this lead to some stuttering when a radio track started.  Is 
this
what you are refering to?  Do you still get the problem with the latest dev 
version?

Original comment by eartle@gmail.com on 18 Dec 2008 at 11:12

[GoogleCodeExporter]

During my early experiments with the code, the first thing I did was disable the
marquee to see what that did. It seemed to help a little bit, but not as much as
turning off the screen updates completely. With the screen updates turned off I 
got
rock-solid playback. I then modified the paint code to pain ONLY the progress 
bar and
I continued to get rock-solid playback 99% of the time.

I have recently noticed that audio becomes a little choppy if you run Mobbler 
in the
background, or if you allow the phone to go into power-saver mode. It seems to
provide the best performance if kept in the foreground at all times.

Original comment by pbextreme@gmail.com on 18 Dec 2008 at 3:07

[GoogleCodeExporter]

Aha, I expect the Draw() function can be optimised quite a bit then, there's 
quite a 
lot in there that doesn't need drawing every single time.

Original comment by hugovk@gmail.com on 18 Dec 2008 at 3:48

[GoogleCodeExporter]

The draw function does quite a bit. It literally repaints the entire screen 
contents
to an off-screen bitmap and then uses bitblt to copy that bitmap to the screen. 
This
2-stage drawing process is common in programming to reduce screen flicker. 
However,
it is only necessary to repaint the progress bar and the blit only it to the 
screen.
This uses up markedly less process time.

Original comment by pbextreme@gmail.com on 18 Dec 2008 at 3:55

[GoogleCodeExporter]

I've got such an issue (music stops playing a 1/10th of a second) if I press 
the left
button (to open Options menu).

Here is my current config :
N98 8Gb fw v30 (fresh install)
Mobbler 0.3.2
Buffer is at its maximum value
Listening radio over 3.5G network

Original comment by deli...@gmail.com on 23 Dec 2008 at 12:23

[GoogleCodeExporter]

We are currently working on putting the audio playback in a seperate thread 
which
should solve this issue and others.  We may still also clean up how Mobbler 
refreshes
the screen in future to make it more efficient.

Original comment by eartle@gmail.com on 23 Dec 2008 at 1:01

[GoogleCodeExporter]

Michael has changed my username on here and so now pbextreme is:

steve.j.punter

That's my real name, including my middle initial. Hopefully this won't create 
too
much confusion.

Original comment by steve.j.punter@gmail.com on 23 Dec 2008 at 10:58

[GoogleCodeExporter]

I have also this stuttering problem, seems to happen when the screen goes to the
power saving mode (the vertical clock bar). It also stutters when it is brought 
from
the power saving. Other than that, it seems to be quite fluent playback.

N95 8Gb, FW3.0, Mobbler 0.3.2

Original comment by juaha...@gmail.com on 25 Dec 2008 at 7:05

[GoogleCodeExporter]

The stuttering problem has gone away due to playing audio in another thread, 
but we
should keep this open to optimise Draw().

Original comment by eartle@gmail.com on 5 Jan 2009 at 2:11

• Changed title: Optimise CMobblerStatusControl::Draw()

[GoogleCodeExporter]

If the text is long enough, the marquee's timer is also always running. It 
could be 
stopped when Mobbler is in the background.

Original comment by hugovk@gmail.com on 21 Jan 2009 at 3:02

[GoogleCodeExporter]

Original comment by hugovk@gmail.com on 21 Jan 2009 at 3:02

• Changed state: Accepted

[GoogleCodeExporter]

r378 in the hugovk branch cancels and resets the marquee timer when Mobbler is 
in 
the background.

Original comment by hugovk@gmail.com on 4 Feb 2009 at 5:14

[GoogleCodeExporter]

I was thinking that we could minimise the number of times we call DrawDeferred. 
 We
call it all over the place indiscrimately.  Maybe we should check that a value 
that
is drawn to the screen is actually changed before calling it.

Original comment by eartle@gmail.com on 4 Feb 2009 at 5:20

[GoogleCodeExporter]

r379: Only call some DrawDeferred() when the value has changed. Commented
out some other calls that don't seem to be needed, though a few of these aren't
very frequent and could remain.

Original comment by hugovk@gmail.com on 5 Feb 2009 at 1:21

[GoogleCodeExporter]

I'm thinking that we should probably put the artist and track name on two lines 
again.

Like this;

(artist icon) (artist name)
(track icon) (track name) 

Both should use the marquee class in case they are too long to fit on the 
screen.

Steve and, I imagine, a few other people don't really like marquees and this 
would
also mean that the scrolling marquee effect is used far less and therefore much 
less
redrawing.

Original comment by eartle@gmail.com on 7 Feb 2009 at 12:02

[GoogleCodeExporter]

I'd stil like to see the album name. Anyway, we could also or instead scroll 
any 
marquee just once per focus, like the S60 music player app does. This would 
hugely 
reduce the amount of scrolling.

(I need to put back one or two of the DrawDeferred()s I commented out.)

Original comment by hugovk@gmail.com on 7 Feb 2009 at 12:37

[GoogleCodeExporter]

[Removing steve.j.punter as owner in case someone else would like to do this]

Original comment by hugovk@gmail.com on 3 Nov 2009 at 11:09