Re: [hatari-devel] How many colors when rendering in Hatari ?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 16/04/2013 21:09, Eero Tamminen wrote:

> Currently this checking & updates are done in very fine-grained way,
> long at the time I think.  The proposal was to do this check line
> at the time, as this can be done much more generic way, just using
> memcmp().

I never measured this, but I'm surprised doing a memcmp (so doing 1 read 
of source and 1 read of destination, before a possible write) is faster 
that doing a "brute force" memcpy (1 read of source and 1 write to dest).

Of course the memcmp can avoid to do the ST memory -> SDL conversion 
when nothing change too much on screen.

At least from my 68000 experience on the ST/Amiga, the direct memcpy 
would be faster.

But what is the balance point ? If the screen is updated each vbl (case 
of a scrolling in a game or most demos), doing a memcmp is clearly a 
loss of time, doing the copy immediatly would be faster.
In the game of a gem desktop, it's quite possible resfresh are less 
frequent and not on the whole screen.

So, at what percentage of screen change is it faster to do a direct 
copy/conversion instead of first comparing buffer ?

I think this would need to be measured in a reproducable way to see 
what's gain of memcmp in different cases/bpp.

Nicolas