Invisible wrote:
> Darren New wrote:
>> Invisible wrote:
>>> In the uncompressed case, you take some data on disk and copy it to 
>>> the framebuffer. 
>>
>> Not quite. You need to align the scanlines, perhaps reorder the R, G, 
>> and B, etc. You can't just blit the whole image to the screen like you 
>> could with an Amiga.  And I'd highly expect that it goes through RAM 
>> on the way between disk and screen.
> 
> Well actually, WMP is playing it back at 200% original size, if you want 
> to be picky about it.
> 
> Even so, moving data from A to B has to be faster than performing highly 
> elaborate arithmetic over it. Unless DMA really does require *that much* 
> CPU power.
> 
>> Depends on how expensive decompressing into the frame buffer is 
>> compared to moving the uncompressed data in and out of RAM.
> 
> Bearing in mind that the video data in question is many, many times 
> larger than any L1 or L2 cache on Earth...

If the decompression CODEC is in any way hardware accelerated you're 
then talking about shoving a small stream down the video pipeline versus 
shoving an enormous stream down the video pipeline. Video memory is very 
fact, hardware MPEG processors are very fast at decoding MPEG, which 
means less CPU usage, less memory bottleneck. In opposition, reading the 
frames into memory, copying the (relatively large) frames to video 
memory, then instructing the video card to flip frame buffers ~30 times 
a second is much more CPU consuming. In the MPEG case, the system will 
feed blocks of stream data to the video card at a much more leisurely rate.

-- 
~Mike

Post a reply to this message