[Scummvm-devel] cost of palette changes

[Johannes Schickel]

On 06/29/2010 12:50 AM, Robert Špalek wrote:
> On Mon, Jun 28, 2010 at 3:02 PM, Max Horn <max at quendi.de 
> <mailto:max at quendi.de>> wrote:
>
>     * Palette updates on modern systems are not "free" like you may
>     remember from your old Amiga/Atari/IBM PC/...
>     * Still, it's not so bad, unless you do many, many *many* palette
>     changes per second, and run on low end hardware such as a Nintendo DS
>     * However, in most cases your user won't be able to see more than
>     30 FPS anyway, so in the end it should be possible to do palette
>     changes just fine
>
>
> that's my case: I just want to do 15-phase fading with short delays 
> essentially just for redrawing the screen.  if the complete redraw is 
> slow, then the fading will be a bit slower, but that doesn't bother me 
> at all.  my question was meant to make sure that the complete palette 
> change is not ridiculously slow (such as much slower than a regular 
> redraw of the complete screen), which might be the case if it was 
> implemented really badly.
>

I am not sure what you mean exactly with a "regular redraw of the 
complete screen", is that just a call to updateScreen, without any data 
changed? If so a palette update will be much slower, since a 
updateScreen without changed data will most probably just abort, at 
least I think most backends now do not do any updates in case nothing 
changed.

If you are talking about a complete (whole screen size) "replacement" of 
the former screen data via copyRectToScreen and then a updateScreen, 
then I think it should take as much time as a palette replacement, since 
in both cases the full screen will be refreshed, i.e. converted from 
8bpp to 16bpp and then the scalers will be applied. That is also a 
reason why you shouldn't first copy new data to the screen, then call 
updateScreen and then (without delay) replace the palette and then call 
updateScreen again, but rather copy over the new data and then directly 
setup the new palette and then finally one updateScreen call.

// Johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20100629/66b46bb2/attachment.html>