@GeneralAntilles

After looking a the conversion function, I can understand why it's not feasible to expect speed (or efficiency) gains calculating an RGB to YUV conversion in run-time:

Y = 0.299R + 0.587G + 0.114B
U = -0.147R - 0.289G + 0.436B
V = 0.615R - 0.515G - 0.100B

Although the formulae are linear and simple, there are two problems (as far as I can see). First, pixel setting is a PRIMITIVE operation and any calculation you add (even a simple one) tends to have a large impact due to the huge amount of times the operation is called. The next is the dreaded floating point, the Achilles heel of the N8x0, and this formula is ripe with floating MULs. Of course, the increased calculation will translate to an increased battery drain, which is not really good for anybody (except the sadists -- bless their little hearts).



@lcuk
Awesome. This has given me a ton of information and a much clearer idea of what's going on.

I'm betting that the simplest and quickest way to do run-time RGB to YUV conversion would be to use a pre-calculated lookup lookup table of conversions rather than run time calculation. Even storing a 16bit RGB to 16bit(?) YUV tabel would only require ~260K of system memory:

(2ByteRBG + 2ByteYUV) * 65536colours == 262144Bytes ~= 262K

[edit]
There is an error in this calculation. The correct size of the lookup should be:
2ByteYUV * 65536colours == 131072Bytes ~= 128K
It is not necessary to store the RGB index as a part of the table
[/edit]

SIDE NOTE: In this instance the N810s 16bit colour capabilities comes in really handy as it keeps the lookup small. 24bit would be quite a bit larger or require an additional bit shift to map the RGB to the YUV. Not terrible, but not ideal either.

Now when SDL sets a pixel, it does it the easiest way possible, by implementing a frame-buffer (block of memory) that you write directy to at a pre-calculated offset (depending on the depth and resolution).

This is where the wonderful compile-time construct the C/C++ macro definition comes in. If all of the pixel setting routines in an SDL app could be found, then they could be easily wrapped with a macro that compares the dynamic RGB with its YUV equivalent on the table *and* writes it to the frame buffer at the desired offset without requiring a costly function call.

To accomplish this, there will have to be a port and inspection of the code, but it *should* be straight forward enough to be done in an afternoon by a gifted porter. I'm guessing that the majority of applications would have their pixel setting done in only in a select few places anyway.

Now, using libQBase as a wrapper to an N810 specific version of the YUV SDL library (RGB/YUV macro lookup), we get minimally ported SDL apps that are spit out not to the X frame buffer, but more directly to the OMAP hardware. I'm guessing that there will be large speed increases for relatively little work!

I know I'm not telling you anything you don't know, just engaging in a little group problem solving. I'm confident that we can bust this nut wide open, figure out a way to squeeze new speed out of existing apps, and use libQBase to enable a new breed of N810 app.


Coding and *compiling* on the go is clearly amazing. I get excited just thinking about it!

How long would you say that battery lasts whilst coding up a few text files? What about reading text files (like documentation)?


I'm hopeful and confident as well. Keep moving forward and I'll see you there.


Cheers

}:^)~
YARR!
Capt'n Corrupt