With current CPUs on the market they have a fast single-core boost but when I use Bluemap rending the core frequency would drop enough that the mspt would reach or exceed 50ms. So would it be possible for you to implement an auto pause when either mspt or tps reach a limit?

Describe the solution you'd like
Add a setting into Bluemap core that allows a threshold of MSPT and/or TPS that would pause current renders.
Another added setting I would like is an over-player limit auto-pause.

Its the actual rendering that is eating up some resources though.

I want to suggest that there come some options to what constitutes an 'update' to a chunk that requires a re-render of the map. So that it does not update chunks as frequently. Certain events are just not very important. ATM, I have no idea when bluemap decides when a chunk requires re-rendering.

Perhaps also some sort of 'time out' so that there is at least a minimum amount of time between renders of the same tile.

If these options already exist, I would like access to them as admin.

ATM, I have no idea when bluemap decides when a chunk requires re-rendering.

When the chunk is saved. A mob moved, a block was changed, lighting was updated, etc.

a moving mob hardly warrants a full chunk re-rendering. I'd rather be able to disable that.

Certain events are just not very important. ATM, I have no idea when bluemap decides when a chunk requires re-rendering.

@SulpherStaer BlueMap updates based on timestamps.
Minecraft sets a timestamp for each chunk that it saves. Minecraft updates that timestamp each time something in that chunk changes. BlueMap takes that timestamp and compares it with the time it has last rendered this chunk. If the chunks timestamp is younger, it will get re-rendered.
That's the most reliable way to get all changes. Listening for events has proven to be very difficult and unreliable..
So there is no way to distinguish between block-changes and entity movement.

However the amount of chunks that get changed without a block change of some sort is probably quite low. Think about gras/saplings growing, sheep eating grass, endermen taking blocks, and mostly: lava spreading some fire to a stone block deep down in a cave ... that's all block-changes ^^

Perhaps also some sort of 'time out' so that there is at least a minimum amount of time between renders of the same tile.

Minecraft also saves changed chunks to disk every 5 minutes or so, certainly not instantly. So that is a "natural" timeout right there :)

a moving mob hardly warrants a full chunk re-rendering. I'd rather be able to disable that.

Entities aren't stored in chunks anymore as of 1.17 so you shouldn't have anything to worry about there.

Implemented in 1.6.2

BlueMap is rendering completely async, off the server-thread. That means it is affecting TPS/MSPT only indirectly if all the CPU-Cores are busy.

Also, implementing a tps-controlled on/off switch would just make bluemap turn on/off in an interval, producing lag-spikes and a slow render-speed.

The best you can do is have a multicore-cpu and give bluemap only so many render-threads that it can't utilize all cores at once, and leaves enough space for the minecraft-server. (See: core.conf > renderThreadCount)

In my opinion a TPS/MSPT-cap is not solving the problem.

I guess my explanation was not thorough enough.
We have just the minecraft proccess that using almost 100% in a single core for the sim thread, and the CPU is doing turbo of 5ghz. If I start with a set render thread of 3 to keep up with the people making changes to chunks and world gen the CPU would turbo to only 4.5ghz making a noticeable mspt increase.
Even though Bluemap is rending completely async from the main process it still has to call for the chunk loading and unloading from the main thread.

The best answer to this is of course is to have more cores to be less effective from this but that's not always possible.

In the end, even if you don't add a TPS/MSPT threshold would you add a player threshold so the server only does rending under the player limit?

If you have only one cpu-core you should never set bluemap to have more render-threads than 1. That will never increase the render-speed. It just makes the render-threads fight over cpu-time on the one core, which increases the scheduling-work for your OS and thus decreases your CPU-clock-speed and everything gets slower.

A player threshold would make more sense, i'll add that on the TODO :)

Even though Bluemap is rending completely async from the main process it still has to call for the chunk loading and unloading from the main thread.

Not really, BlueMap is loading chunks itself, from the world-files.

The only thing it does is listen to some events, but that is no load on the main-thread at all.