Raster - paletted: fix slow rendering with huge number of classes

[elpaso]

Fix #56652

Alternate fix for #56652, see #56677

Test run without this PR with 50K classes:
24.548s

With this PR:
1.599s

The (insane) test case of #56652 produces a noticeable freeze of about 2 seconds on my machine.

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit e2ea46f)

[nyalldawson]

Thanks @elpaso ! I wonder if we shouldn't still skip the whole logic in extreme circumstances. Is there any harm in doing so? A 1.5 second delay would still be nice to avoid if there's no harm in skipping this

[elpaso]

Thanks @elpaso ! I wonder if we shouldn't still skip the whole logic in extreme circumstances. Is there any harm in doing so?

Yes, that would break RAT on-the-fly reclassification (but see later for the missing uses case).

A 1.5 second delay would still be nice to avoid if there's no harm in skipping this

I honestly do not think this is an issue, there is a much longer (~30 seconds) freeze when creating 50K classes before entering the renderer but the more important question is: what's the use case for a paletted renderer on a continuous floating point raster that would yield 50K classes?

I think we shouldn't change the logic here, if you want you can add a safeguard at the GUI level before creating the renderer that would warn the user about the potential nonsense of creating a paletted renderer with such a huge number of classes.

If there is a use case for that (which I doubt) then collapsing classes is probably something we would like to do in that case.

[elpaso]

It's a pity this didn't make into today's release.

Let's hope for the next.