There is a comment inside GameSetup.cpp:

// Need some stuff for terrain movement costs:
// (TODO: this ought to be independent of any graphics code)
new CTerrainTextureManager;
g_TexMan.LoadTerrainTextures();

Doesn't it contradict to your sentence?:

As a side effect, we don't actually need to inform the simulation when the terrain textures change so don't do that.

Seems reasonable to me.

It seems RENDERDATA_UPDATE_COLOR wasn't used even before rP24124.

In rP26142#55427, @wowgetoffyourcellphone wrote:

This may have sped up the loading, but now the previews are very aliased and difficult to use.

In rP26215#55398, @wraitii wrote:

Only seems to happen with this combination of settings.

In D4441#189637, @Langbart wrote:

Silhouettes work, but they look less transparent than in A25b and are therefore more eye-catching. If the colour for the silhouettes can be made a little more transparent with no extra effort, that's good, otherwise I'll get used to it.

Fixes state changes check.

In D4441#189599, @Langbart wrote:

Apply the patch and compile the game

Ok, worked with the pull0ad function. rP26226 + D4441 (but with diffID 19480)

Make sure the game looks the same for GLSL and ARB

Yes, i think so. Took some screenshots.

Thank you for your testing!

@nwtour and @Langbart could you test performance with this patch?

In rP26215#55398, @wraitii wrote:

Only seems to happen with this combination of settings.

Fixed in rP26223.

Removes material usages.

Seems to work.

In D4425#188797, @wraitii wrote:

Mh, you're skipping over the bit where it won't stuck :P . Either the tasks will be cancelled before they're started, and the the main thread will compute paths, or they'll actually be started, so they won't hang on texture conversion.

In D4425#188790, @wraitii wrote:

I believe the simulation (pathfinder anyways) ends up running computations on the main thread anyways right now, so it wouldn't get stuck.

It's written so that it will stuck.

Also it seems that converting many textures may stuck the game, particularly simulation. If threads are overused by the converter.

In D4423#188755, @nwtour wrote:

So in principle there should be no performance changes

It depends on implementation, it uses glDrawRangeElements with max numbers. In some particular implementation driver might prefetch data for caches according to the range, especially if it sees that the range is continuous.

There are forgotten dependencies.

In rP26185#55224, @Freagarach wrote:

DeviceCommandContext.cpp
In file included from ../../../source/lib/precompiled.h:74,
                 from ../../../source/pch/graphics/precompiled.h:18,
                 from ../../../source/renderer/backend/gl/DeviceCommandContext.cpp:18:
../../../source/renderer/backend/gl/DeviceCommandContext.cpp: In member function ‘void Renderer::Backend::GL::CDeviceCommandContext::UploadTextureRegion(Renderer::Backend::GL::CTexture*, Renderer::Backend::Format, const void*, size_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t)’:
../../../source/renderer/backend/gl/DeviceCommandContext.cpp:89:48: warning: comparison of unsigned expression in ‘>= 0’ is always true [-Wtype-limits]
   89 |                         ENSURE(level == 0 && 0 <= layer && layer < 6);
      |                                              ~~^~~~~~~~
../../../source/lib/debug.h:295:22: note: in definition of macro ‘ENSURE’
  295 |                 if(!(expr))\
      |                      ^~~~

(This might have been here before.)

Fixes notes.