Darren New <dne### [at] sanrrcom> wrote:
> The only way I can see it being slower is there's actually two different 
> sets of code, based on what order things are in, such that (for example) 
> one branch adds two numbers using "+" and the other does some magic to 
> add 0xA000 and 0xA000 to get 0x4001 automatically without actually 
> treating them as binary integers. Is that what you're referring to?

  If I remember correctly, what mplayer does (well, some of its video
filters, actually) is to build 4-byte pixels into words and then it
writes those pixels on a per-word basis to some output buffer. Naturally
the endianess of the architecture determines if the R channel goes to
the lower byte or the upper byte of the word.
  If endianess is not taken into account, in architectures with the other
endianess the color channels will be effectively swapped. (I know this
from actual experience.)

  Naturally it could write the bytes themselves, ie. on a per-channel
basis instead of a per-pixel basis, but those would be 4 writes instead
of 1. Another possibility would be to build the word always in the same
way and have the "compiler reverse it in architectures with the other
endianess" (if that's even possible in any compiler of any language),
but that would mean a bunch of extra steps in that other endianess
architecture, for no good reason.

-- 
                                                          - Warp

Post a reply to this message