[PATCH v2 3/3] gdi32: Use a global cache for frequently used color tables for RGB value lookups.

[Gabriel Ivăncescu]

On 08/04/2021 10:31, Huw Davies wrote:
> On Wed, Apr 07, 2021 at 04:34:15PM +0300, Gabriel Ivăncescu wrote:
>> On 07/04/2021 12:03, Huw Davies wrote:
>>> Yeah, I'm not convinced, not even close.  You're going to have to
>>> provide some pretty good evidence, with real world apps, that this is
>>> necessary over a local, lazy-init solution.
>>
>> Well a simple real world test is in the bug report with Winamp's Credits,
>> while it's not that important, it's easy enough to test compared to, say,
>> games.
>>
>> When I tested on Windows it does seem to cache color tables between calls
>> because it was just way too fast, unless they have some voodoo algorithm to
>> generate the color table extremely quickly on each call.
> 
> A possible algorithm[1] has been suggested (twice).  To make progress here it
> would be a good idea to try that.
> 
> Huw.
> [1] a local lazy-init.
> 

Well I guess my persuasion failed. I didn't do extensive tests, but the 
lazy init seems to still use a lot of CPU when the framerate is high 
(with the Credits tab). It's not particularly a problem since my other 
patch has similar performance without the global cache, but...

I still think this will be a "dead end" and this code will never see 
further improvement due to complicating the global cache even more (and 
otherwise we'd have to throw the lazy init away, which nullifies the 
point). And it's unfortunate that Windows still does it faster, and has 
a cache for sure.

But anyway I'll send the lazy init way then, since at least they're 
still better than what we have currently...