Slowness of pattern display in Wine is at least partly due to the work-around I added in r4043 . Otherwise the current row highlight would be jumpy and flickery like crazy. Now, the flickering could be attributed to an incompatibility in Wine because native Windows behaves differently, however, the way OpenMPT does its drawing of the pattern display here is way suboptimal and IMHO also massively contributes to the problem. Correct behaviour for the way OpenMPT does its drawing is also not at all specified by Microsoft. The work-around that gets applied on Wine basically redraws the whole thing on every row change, which can be noticeably slow, especially on very slow CPUs like an Intel Atom ZxxxxF.

Oh, I'd wish this was there! +1

Since I have Intel(R) Core(TM) i3-6006U, the most of VSTs work perfectly for me. Anyway, this feature would be very cool for slow-core CPUs (like 4 core Z*** intel processors) or for heavy VSTs that would make audio lag even on i3.

Yes, I will be upgrading to a multicore computer soon. Will I have to keep my old single-core, XP computer so I can run openMPT as efficiently as I have? Does this mean my new computer will offer me no speed advantage for openMPT?

It most likely will because there are tons of other ways OpenMPT can profit from a more modern CPU (e.g. updated instruction sets that OpenMPT can make use of).
In particular, OpenMPT (or any other application) does not have to fight over the resources of a single CPU core. You just currently cannot expect that OpenMPT will render 8 times faster if you have 8 cores, that's all.

Well, If I use 11 VSTs in the same time, the sound is starting to crack even on i3. We need this feature.

Re-iterating the known facts doesn't make implementation any easier.

I have already stated this otherwhere (possibly on IRC, cant remember right now):
Pushing forward for this feature right now would very likely require more effort in total than what would be required when we delay this feature until after plugin handling gets refactored and restructured and in particular cleaned up.
Implementing this short term could require implementing kind of a hack now, requiring a proper re-implementation later on, and thus wasting a lot of development time in the process.

@Manx: it was indeed on IRC, towards me. :)

quoting IRC EsperNET #modplug 2017-09-18 for future reference (I shortened the log to the relevant parts):

20:58 <@LPChip> Saga_Musix: question. I know we talked about this in the past, but how much can OpenMPT utilize multiple cores?
20:59 <@Saga_Musix> the renderer is single-threaded. plugins may make use of more cores if they want to
20:59 <@LPChip> so it is up to the plugin to use mutiple cores?
21:00 <@manx> openmpt will basically use 1 for audio, 1 for the gui
21:00 <@Saga_Musix> yes
21:00 <@LPChip> I see... okay, that explains why my idea didn't work.
21:00 <@Saga_Musix> but only very few plugins are multi-threaded, because most of the time there is no opportunity to really take advantage of multiple cores for a single plugin
21:01 <@LPChip> I was hoping if I had many plugins all loaded directly into OpenMPT, that they would magically use all my cores. Instead they all load in the same core, so I reach 1 of my 8 cores full and stutter begins
21:03 <@LPChip> in theory, would it actually be possible to create multiple threads of OpenMPT so different VST effects and instruments get loaded in different threads to spread out the load over the entire processor?
21:03 <@manx> yes, that would be possible in theory
21:04 <@LPChip> is there such feature request already? :P
21:15 <@manx> LPChip: yes: https://bugs.openmpt.org/view.php?id=923
21:17 <@manx> it's also not quite as simple as it seems
21:18 <@manx> in particular, i'm rather hesitent to include more kind-of-hacks around plugins at the moment, i'd rather see a cleaner re-implementation of all plugin handling
21:19 <@LPChip> manx: I see... I'm in for that. can you make it ready by tomorrow?
21:20 <@manx> there are a couple of things worth implementing in that area: more flexible routing, plugin delay compensation, suppor tfor foreign plugins (i.e. linux plugins when running on wine)

[...]

21:38 <@LPChip> the plugin bridge doesn't do this, correct?
21:38 <@LPChip> or does that run in its own thread?
21:39 <@manx> the plugin bridge runs in its own process and thus thread
21:39 <@LPChip> oh okay
21:39 <@LPChip> that is worth investigating
21:39 <@manx> however, i think it runs in lock-step with the main audio thread, so it does not actually parallize anything
21:39 <@LPChip> ah. okay
21:39 <@manx> we would need to ad explicit support for that, which would be, in its most simple form, at the expense of additional latency for the bridged plugin
21:40 <@LPChip> yeah
21:40 <@manx> but, i'm not sure if it is actually worth going that route from a development effort point of view, given the other things that need to be adressed in that area
21:40 <@LPChip> I guess the simplest form would be to send midi notes to an instance that runs in its own thread, and let that threat work whatever it wants