[Scummvm-devel] Bitdepth/pixel format API concerns

Johannes Schickel lordhoto at gmail.com
Sat Jun 13 20:18:13 CEST 2009


RafaƂ Rzepecki wrote:
>> Thus I agree with Max' proposal:
>>
>> 1) Let the backend worry about conversion.
>> 2) If an engine expires too much performance loss on an specific
>> backend, try to optimize the engine with format conversion on load if
>> possible.
>>     
>
> I can't help but feel this whole discussion is an acute case of
> premature optimalization. How expensive is colorspace conversion
> anyway? My guess is, not very much. Most (all?) backends do full
> screen conversions anyway, since the hardware is usually truecolor.
> How much more expensive could full screen pixel swizzling be compared
> to palette lookup?
>   

Well yes for CLUT8 they do a palette lookup. I would think that a 
palette lookup is faster than BARG to ARGB or something conversion 
though ;-). Anyway yes it is a bit premature optimization.

> My vote is (although I'm not sure if I have any right to vote, so
> let's make it "my voice") to KISS it. Let the engine request however
> exotic colorspace it wants (as long as it's supported by our
> conversion routines, ie. the PixelFormat struct) and let the backend
> worry about how to draw it. Unless the engine just wants whatever
> high/truecolor mode (as when doing conversion anyway), then let it ask
> for any mode and let it find out what mode it was provided.
>   

That's exactly what Max proposed too. Just check the lines you quoted 
above ;-).

> All this talk is probably more text already than all the code would
> have been, while it isn't clear (at least to me) than any such clever
> optimizations (at risk of leaking abstraction, no less), which would
> certainly need such discussions, are at all neccessary.
>   

Probably.

// Johannes




More information about the Scummvm-devel mailing list