[Scummvm-devel] Bitdepth/pixel format API concerns

[Rafał Rzepecki]

On Sun, Jun 14, 2009 at 6:12 PM, Johannes Schickel<lordhoto at gmail.com> wrote:
> Rafał Rzepecki wrote:
>> 2009/6/14 Johannes Schickel <lordhoto at gmail.com>:
>>
>>> Well we are not talking about these problems for high end hardware though.
>>> We still have to support some ports with processors from 200-500MHz. (mostly
>>> talking about WinCE on ARM here)
>>>
>>
>> I understand, but the relative difference is unlikely to change. Plus
>> it's another argument for the backend to do the conversion: it can
>> easily utilize ASM conversion code or even hardware support, should it
>> prove to be necessary.
>>
>>
>
> Well it's not exactly an ultimate argument for the backend doing the
> conversion. Of course if the game would require to do the conversion
> every time it copies data to the real screen, the backend might have a
> more sophisticated/faster approach for conversion due to more knowledge
> about the hardware run on.
>
> On the other hand if the engine is able to do one conversion for
> multiple display instances it might be still faster overall to do that
> engine wise. An example might be actor drawing here, the engine might
> load the graphics data into memory once, doing the conversion there and
> then be able to display the data without any need to conversion later on
> (neither engine nor backend wise).
>
> I made up some simple test as you did for the latter case. Here my
> results of your RGB555->RGB565 conversion on every screen update:
>
> $ time ./test2 10000
> Running 10000 iterations of swizzling RGB555->BGR565 for 640x480 fullscreen
>
> real    0m17.619s
> user    0m17.614s
> sys     0m0.001s
>
> And here for my simple before hand conversion:
>
> $ time ./test1 10000
> Running 10000 iterations of beforehand conversion RGB555->BGR565 for
> 640x480 fullscreen
>
> real    0m0.615s
> user    0m0.610s
> sys     0m0.004s
>
> That looks a bit different now ;-). (Of course my system might cache a
> bit in that because of that memcpy call).

Sure, that's why I opted for the mixed approach which is slowly
beginning to be the consensus here - ie. if the engine knows better,
let it, and if not, let it not care.