[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