It would be great to hear how fast this can run on the XO board we have. It easily runs at 20+ frames per second on my Panasonic.
Kim/Yoshiki, it would be great if you could tell Becky the frame speed result on the XO board.
Cheers,
Alan
Alan,
It looks like it is doing 3.1 fps or such.
BTW, our JPEG decoder and MPEG decoder are compiled to use platform independent code. The MPEG decoder comes with MMX and 3DNow assembly code so we may be able to make it run faster just with different compile configuration. For JPEG, there should be some code around that uses such instructions. (Back when I was playing with iPAQ, I tried "Intel Performance Primitives" that provides such code. It gave us factor of 8 or such improvement over JPEGReadWriter2.)
If it is important for B-test, we can at least try and see how fast MPEG decoding can be.
-- Yoshiki
Hi Yoshiki --
It would be great to see how fast both MPEG and JPEG decoding could be ....
Cheers and thanks,
Alan
At 06:46 PM 10/11/2006, Yoshiki Ohshima wrote:
Alan,
It looks like it is doing 3.1 fps or such.
BTW, our JPEG decoder and MPEG decoder are compiled to use platform independent code. The MPEG decoder comes with MMX and 3DNow assembly code so we may be able to make it run faster just with different compile configuration. For JPEG, there should be some code around that uses such instructions. (Back when I was playing with iPAQ, I tried "Intel Performance Primitives" that provides such code. It gave us factor of 8 or such improvement over JPEGReadWriter2.)
If it is important for B-test, we can at least try and see how fast MPEG decoding can be.
-- Yoshiki
I wonder if the Flash file base for the images, etc., might be a big problem here also?
It's striking how fast this runs on my (not so fast) Panasonic laptop.
Cheers,
Alan
---------
At 06:46 PM 10/11/2006, Yoshiki Ohshima wrote:
Alan,
It looks like it is doing 3.1 fps or such.
BTW, our JPEG decoder and MPEG decoder are compiled to use platform independent code. The MPEG decoder comes with MMX and 3DNow assembly code so we may be able to make it run faster just with different compile configuration. For JPEG, there should be some code around that uses such instructions. (Back when I was playing with iPAQ, I tried "Intel Performance Primitives" that provides such code. It gave us factor of 8 or such improvement over JPEGReadWriter2.)
If it is important for B-test, we can at least try and see how fast MPEG decoding can be.
-- Yoshiki
Alan,
I wonder if the Flash file base for the images, etc., might be a big problem here also?
It could be but I'd imagine it is not significant. I'll measure the raw data throughput on the board later. They say the read through put on the A-board is something like 2.5MB/sec. Assuming this ideal bandwidth achieved, the JMV file is about 1.5MB, so half a second is spent on reading over 20 seconds or so play time.
With their CaFe chip on later revision of boards, the bandwidth is supposed to be 10 times faster.
It's striking how fast this runs on my (not so fast) Panasonic laptop.
Yeah, it is about one order of magnitude range with my Panasonic laptop.
-- Yoshiki
Alan,
It could be but I'd imagine it is not significant. I'll measure the raw data throughput on the board later. They say the read through put on the A-board is something like 2.5MB/sec. Assuming this ideal bandwidth achieved, the JMV file is about 1.5MB, so half a second is spent on reading over 20 seconds or so play time.
From a USB memory in VFAT, it seems to be able to do 13MB/sec or such.
And, Linux uses free memory space as file buffer cache (and OLPC will have some memory-based filesystem (tmpfs). If I read a file from cached data, Squeak can do over 70MB/sec.
Our MPEGPlayer seems to spend so much time on updating sliders and buttons and invisible subtitle. Only about 60% of time seems to be spent for decoding (about 30%) and displaying (about 30%). We could do some more optimization.
-- Yoshiki
That's interesting!
Cheers,
Alan
------------
At 10:48 AM 10/12/2006, Yoshiki Ohshima wrote:
Alan,
It could be but I'd imagine it is not significant. I'll measure the raw data throughput on the board later. They say the read through put on the A-board is something like 2.5MB/sec. Assuming this ideal bandwidth achieved, the JMV file is about 1.5MB, so half a second is spent on reading over 20 seconds or so play time.
From a USB memory in VFAT, it seems to be able to do 13MB/sec or such.
And, Linux uses free memory space as file buffer cache (and OLPC will have some memory-based filesystem (tmpfs). If I read a file from cached data, Squeak can do over 70MB/sec.
Our MPEGPlayer seems to spend so much time on updating sliders and buttons and invisible subtitle. Only about 60% of time seems to be spent for decoding (about 30%) and displaying (about 30%). We could do some more optimization.
-- Yoshiki _______________________________________________ Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
what I found impressive is that I was just able to drag and drop the attachment into my OLPC image and was prompted with "play in mpeg player" and it just worked!!! Kim
At 9:33 AM -0700 10/11/06, Alan Kay wrote:
It would be great to hear how fast this can run on the XO board we have. It easily runs at 20+ frames per second on my Panasonic.
Kim/Yoshiki, it would be great if you could tell Becky the frame speed result on the XO board.
Cheers,
Alan
Attachment converted: MAC OSX 10.4.8:becky.jmv ( / ) (00280C14) _______________________________________________ Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
etoys-dev@lists.squeakfoundation.org