<div dir="ltr">On Wed, Aug 20, 2008 at 2:27 PM, Barry Clearwater <span dir="ltr"><<a href="mailto:barryc@bcsystems.co.nz">barryc@bcsystems.co.nz</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I take the point that a high def signal is getting heavily compressed,<br>
but we *are* talking about well known compression algorithms are we not?<br>
Should somebody be writing a more optimised piece decompression code, or<br>
in a lower level language? (cough - assembler anybody!!??)<br>
ITs just a 2D picture, our systems are capable of rendering 3D on the<br>
fly...<br>
I must be missing the point and over simplifying it somewhere.</blockquote><div><br>Our systems are capable of complex 3D rendering because they have hardware support. But 2D vs 3D really has nothing to do with it. I can assure you that plenty of optimisation is happening but the algorithm is sufficiently complex that most CPUs cannot run it in real time regardless of optimisation. The same situation occurred in the early days of mpeg2 as well (and even jpeg before that).<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><pride speaking><br>
No way should windows boxes out-compute a gnu/linux system.<br>
</pride></blockquote><div><br>Well the Windows systems can off load some of the processing to the graphics card and the Linux system cannot. Specialised hardware can make a huge difference to performance. That's why we have powerful processors on our graphics cards.<br>
<br>Cheers,<br>Steve<br></div></div> <br></div>