Hard-coded enums may go out of sync with code
Closed this issue · 7 comments
This file contains lots of enums copied from code: https://github.com/mbebenita/aomanalyzer/blob/master/src/components/analyzerTools.ts#L904
But they can go out-of-sync with code (with or without some experiments enabled).
So, for example, if I add new prediction modes in code, the analyzer isn't able to display the colors for that mode correctly.
Why not auto-grab these from code, and use the 'COLORS' array directly to assign colors?
We used to assign colors based on a hash of enum names. This resulted in lots of hash collisions and it didn't look very good, which is why we moved to a hard coded list of colors. We should however assign a color if one doesn't exist in the hard coded list.
We should however assign a color if one doesn't exist in the hard coded list.
That's probably OK, yes.
What I was thinking is that the enum value can index into the COLORS array you have, so that you can still use hard-coded set of colors. (We can reorder the COLORS array if needed, for this, so that the colors actually look good).
I'll leave it to you about picking one of the two solutions.
Do you have a AWCY run I can test against? (One that has enums that are not listed in the hard coded list.)
Fixed by 2185fe5. I changed it to fall back to a COLORS[hash(labe)] if the color doesn't exist in the palette.
Thanks for the bug report.
Thanks for the quick turnaround!