There are two kinds of "decorated" mouse cursors. The basic are single-sprite cursors, those are most of the construction tools. In the original graphics the construction tool is integrated in the cursor itself:

In OpenGFX the tool appears to be a separate sprite next to the cursor, but it's actually still a single sprite:

When you drag a vehicle in a depot, the vehicle graphics is used for the mouse cursor instead, the cursor is still only a single sprite then.

How does that relate to whether the cursor is locked in position or not when scrolling?

@PeterN I think @nielsmh is referring to my comment under Limitations about the cursor being drawn incorrectly.

@nielsmh Hmm... I see what you mean. In that case, I think there will need to be an Emscripten-specific code path added for the cursor rendering, as the only way I know of to change the cursor appearance without having OpenTTD draw it itself is to use CSS.

I think having an alternate cursor code path would be useful regardless, as there are some requests to support a high-contrast cursor style. In my mind that would be basically skipping the baseset for the cursor graphics and draw something custom instead.

I've discovered that adding cursor: none !important to the canvas CSS in os/emscripten/shell.html will actually override Emscripten's cursor logic and force the software-rendered OpenTTD cursors to always get drawn. That is probably a good enough compromise for now.

The side effect is that the cursor rendering will now be dependent on OpenTTD's frame rate, but that's also how it works on the normal ports. On my machine I don't see any noticeable lag while testing it.

I'm going to mark this as ready for review as I haven't noticed any bugs while testing it.

@TrueBrain There were some valid concerns raised about changing the default scrolling mode in #9150.

So, is there a way of conditionally choosing the default using the preprocessor inside settings.ini?

Not sure if the ongoing refactoring enables/disables that.

Check for stuff like APPLE to see how that works, but yes, you can change defaults for settings depending on #defines. The question of course is: do we want that in this case :D

Looks good to me. If you wouldn't mind rebasing and squashing your commits to a single one, that would make the commit checker happy too :D Tnx!