User:Nrp/Weekly updates/20080628: Difference between revisions

From OLPC
Jump to navigation Jump to search
Line 14: Line 14:
== Wednesday ==
== Wednesday ==
* Merged colorspace branch back into master
* Merged colorspace branch back into master
* starting using cProfile to figure out what was being slow. The conclusions: pygame inits the olpc display to 16bits per color, so blitting the 8bit surfaces to 16bit display surfaces takes additional time. The main thing slowing down my RGB -> HSV conversion is actually finding the max and min of 3 values in each pixel (r, g, b), which actually takes 23ms on a 640x480 image. This doesn't sound like much, but keep in mind that to run at 30fps, each frame has to take less than 33ms to process and display. It takes around 22ms to blit and flip a 320x240 image, so processing each frame has to be a LOT faster. I feel like blitting shouldn't take that long. Perhaps there is some way to fix it.

Revision as of 00:46, 26 June 2008

Saturday

Sunday

  • Finished a bunch of colorspace conversion functions

Monday

  • Uploaded the v4l and colorspace branches to the git repository on my server
  • Debugged some silly colorspace mistakes
  • First attempts at YUV -> HSV direct conversion. It seems nobody has come up with these formulas before. I'm probably just going to approximate it, but it will still involve faking trig with ints.

Tuesday

  • Fixed a bunch of colorspace conversion mistakes
  • Tested performance on the XO (needs to be faster)

Wednesday

  • Merged colorspace branch back into master
  • starting using cProfile to figure out what was being slow. The conclusions: pygame inits the olpc display to 16bits per color, so blitting the 8bit surfaces to 16bit display surfaces takes additional time. The main thing slowing down my RGB -> HSV conversion is actually finding the max and min of 3 values in each pixel (r, g, b), which actually takes 23ms on a 640x480 image. This doesn't sound like much, but keep in mind that to run at 30fps, each frame has to take less than 33ms to process and display. It takes around 22ms to blit and flip a 320x240 image, so processing each frame has to be a LOT faster. I feel like blitting shouldn't take that long. Perhaps there is some way to fix it.