<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 06/29/2010 12:50 AM, Robert Špalek wrote:
<blockquote
cite="mid:AANLkTimo53q5vQ_-UqngGESZZzk_L7ptS5AR3GnsfLk4@mail.gmail.com"
type="cite">On Mon, Jun 28, 2010 at 3:02 PM, Max Horn <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:max@quendi.de">max@quendi.de</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">*
Palette updates on modern systems are not "free" like you may remember
from your old Amiga/Atari/IBM PC/...<br>
* 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<br>
* 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<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<br>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
// Johannes<br>
</body>
</html>