On Thu, 20 Apr 2006, RaeNye wrote:

Hey

Nice to see a new face digging into core details!

> 1. Currently each PutPixel costs 2 mem reads, 4 mem writes and some shifts
> (all because of the 18-bit thingy).

You're talking X5's lcd driver here. Just pointing this out to the audience.

> Would double-buffering help?

It certainly might, but it would possibly also make it worse for the cases
when lots of stuff change.

> How can this be profiled, btw?

I suggest:

Pick a plugin that does lots of things on screen (like plasma or perhaps Doom)
and add a FPS counter. Rewrite the lcd driver. Rerun the FTP measure.

I know Jens Arnold has a few (other) ideas on how to improve this driver.
Including rewriting parts in assembler.

> 2. I might be terribly wrong, but can we shut down all GUI code when the
> backlight is off? Yes, this means WPS refreshes, scrolling, etc.

We've discussed this in the past but we haven't made it do this yet. The
tricky part is the required refresh when we enable the LCD again.

On the X5 we don't even switch off the LCD atm when the backlight goes off...

> 3. GNU's memcpy() and memset() are not using all possible registers

We don't use GNU's versions, we use Jens'! Are you referring to our versions
in firmware/common/ ?

> The iAudio firmware contains smaller and faster versions, which *I* cannot
> contribute to Rockbox -- as that would be considered code theft -- but you
> can write as you only heard the general idea :)

You can still _read_ other code and being inspired by that improve other code
_without compying_ it. At least for most purposes in most countries.

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/