(cut some stuff for readability)
Lidj wrote:
>
> Niels Roest wrote:
>
>> Lidj wrote:
>>
>>> Hi Niels,
>>> Appreciate for your help.
>>>
>>> 1. I have try DSFLIP_NONE to see the playing rate, it still take 1.9s to
>>> play 30 frame.
>>>
>>> 2. I use "for" loop to playing 30 frame, and measure how long it take.
>>> like this
>>>
>>>
>>> <=========
>>> while (!quit) {
>>>
>>> lastftick = myclock();
>>> for(i=0;i<FRAME_NUMBER;I++){
>>> CopyYUVData(temp[i], videosurface); //temp[i] is 30 frame
>>>
>>> /*Flip the buffers of videosurface on the video layer*/
>>> videosurface->Flip(videosurface, NULL, DSFLIP_WAITFORSYNC);
>>> }
>>> lastftick = myclock()-lastftick;
>>> printf("playing %d buffer time used: %ld s\n", frame_number,lastftick);
>>>
>>> }
>>> =========>
>>> output: playing 30 buffer time used: 1941 s
>>>
>>> Ok, I assume you put DSFLIP_NONE, and not DSFLIP_WAITFORSYNC as you
>>> copied here above.
>>> What I actually mean if you have done a theoretical throughput
>>> calculation, based on the capabilities of your hardware. In other words:
>>> how do you know for sure that 30fps is possible?
>>>
>> About this, I just simply think: In windows, they can driver graphic
>> card to support 30fps
>> it should be able to support in arm-system?
>>
>>
I assume you mean that you can run Windows on your ARM system, where
your performance is as you expect? And the rest of the system is
configured the same (with double buffering, screen resolution, screen
format, etcetera) ? Otherwise you risk comparing apples to pears.
>>> 5. In fact, my example just can play each single frame in loop. :o
>>> And it takes almost 2 seconds to play 30 frames(too slow, my main
>>> issue).
>>>
>>> Here is my guess, maybe root cause is on memcpy too slow?
>>> The XGA UYVY file size is 1.5mb/frame, memcpy can't move data to
>>> "videosurface" in time.
>>> So it can't meet 30frame/s. Is this guess reasonable?
>>>
>>> That is possible.
>>> You can simply remove the memcpy and see what happens.
>>>
>> if I remove memcpy, the process of moving data to videosurface will
>> skip.
>> Therefore it will do nothing on this test program, also output nothing.
>>
>>
That's not necessarily true.
The Flip() will copy data from the back to the front buffer, if you
configured it like that.
You can try front-only to see if this speed things up.
>> But I don't know use what function to replace memcpy.
>> memcpy is the faster way to copy data.
>>
>>
..apart from DMA.
if your graphics accelerator and directfb support it, you can copy the
data first to a off-screen surface, and then use that to Blit() it to
the surface of your display layer. Of course you need to make sure that
your DMA engine can access the off-screen surface, so maybe you need to
put it in video memory.
hth
Niels
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
