In D4768#202986, @phosit wrote:

And how well does your task manager work with zero threads?

Works fine as said above.

In D4768#202981, @phosit wrote:

static_assert(MIN_THREADS > 0 && MIN_THREADS <= MAX_THREADS);
numberOfWorkers = Clamp(std::thread::hardware_concurrency(), MIN_THREADS, MAX_THREADS) - 1;

As pointed by Stan it's wrong.

In D4768#202979, @phosit wrote:

That's not different with your patch.

That's not about my patch. That's about your sentence:

In D4768#202977, @phosit wrote:

MIN_THREADS is always not zero: starting an application with zero threads has no sense.

Which is wrong for our case.

In D4768#202977, @phosit wrote:

MIN_THREADS is always not zero: starting an application with zero threads has no sense.

Unfortunately because of implicitness it doesn't work how you imagine it. You can set both MIN_THREADS and MAX_THREADS to zero and it will work perfectly fine.

In D4768#202975, @phosit wrote:

Why do we need an extra function GetDefaultNumberOfWorkers?

Explicit relation between hardware_concurrency and number of workers, might be clamped though.

Reverts PDB.

icu::Locale is about 200 bytes, if there is no too much vector resizing then changes make sense.

I don't think to add a proposal interface is a good idea. We already have a plenty of code (not the best quality) to support. Also I prefer to have as simple interface as possible.

In D4761#202748, @phosit wrote:

it does compile on all os. Ther might be some in architecture specivic code but a grep yields nothing.

Have you checked MSVC output in case of an error?

LGTM.

Might make sense to enable LTO before committing, because I'm not sure that returning Quad by value won't have copies with MSVC.

Don't we have regression here?

I agree that a red button looks like people shouldn't interact with it, or interact only in emergency.

I can’t say it’s a performance fix, because the very high setting is for high-end hardware, where it works fine. It’s more like a logic fix.

Single test replays isn’t enough for such kind of changes.

Please add a context to the patch. The patch looks ok.

In D4682#199600, @phosit wrote:

Is there generaly a need to remove ps/Singleton? should i also work on that?

By removing that you semantically won't remove singletons from the code, only safety checks.

Fixed in rP26922.

Added the same hack as for GLSL.

In D4681#199033, @wraitii wrote:

Isn't the ticket a bit of a 'wont fix' though? Seems to me under the current shadow technique & without filtering you can't really prevent such artefacts entirely, can you?

Yep, there are few possible ways.

It doesn't fix the ticket, so the ticket must not be closed. But the fix might be committed as soon as accepted until we have a proper solution.

LGTM.

What happens if there multiple spaces in the end? It needs at least tests.

In D4669#198598, @Stan wrote:

This will affect the userreporter, do we care @vladislavbelov

Rebase.

In D4614#198214, @phosit wrote:

I moastly agree with you but I think a friend declaration is worse since it is not testable.

I'm not happy about both of them, but okay.

Fixes @Langbart note.

Ideally I'd prefer to not have back relation CFont > CFontManager (via callback). I don't think CFontManager being friend of CFont is worse than that, because it makes CFont a pure data holder without much logic.

In D4654#198195, @mastoras wrote:

1. Apply the patch and compile the game -> OK
2. Check that minimap looks like before with GL and GL ARB backends -> OK
3. Check that map revealing looks like before -> OK

Thank you for testing!

In D4654#198039, @gameboy wrote:

@vladislavbelov I wonder what this patch has changed? Please！