Low FPS Armature

[Domiek]

Sorry, another report to give. I’m experiencing a slow armature going anywhere from 6-15fps. This is just the rigify armature with all shapekeys/drivers disabled, everything hidden in the viewport other than the armature itself.

‌

After converting an 8.1 char and loading in all the morphs/facs/jcm’s etc, and having the char fully prepped for production, I noticed I was getting 14fps on just the subd0 mesh + armature. After disabling all shapekeys/drivers/morphs, the fps remained the same.

Everything disabled in viewport

‌

‌

Disabled drivers, 15fps

‌

‌

Removing drivers brings the fps back to full although I’m uncertain which exact drivers were removed and how this will impact posing/morphs.

‌

‌

Re-enabling the base 18k poly mesh with all modifiers disabled brings the fps back to a crawl anywhere from 6-15fps. Removing all shapekey drivers has no effect on fps. Disabling the armature and moving just the base mesh by itself gives me full 24fps.

‌

‌

I’ve been using Diffeo for about a year and in the past this exclusively with Genesis 3 figures. Loading an old Gen 3 file, I’m at my max fps setting of 24. I’ve been able to animate two Gen 3 figures at the same time while maintaining 24fps. I’m not sure why Gen 8.1 is giving me issues.

‌

‌

I’m on Windows 10 with a 1900x Threadripper and a 3090 using developmental build of Diffeo.

[Domiek]

Formatting

[Thomas Larsson]

First, did you exclude the meshes (checkbox), or did you just hide them (eye icon). The latter does not remove them from the view layer, so they still eat up resources even if they aren’t visible.

‌

Each loaded morph generates several drivers for the rig object and the armature. Those are evaluated even if the meshes are hidden, and that takes quite some time if there are many morphs. Unfortunately, these are drivers that belong to the armature, because they drive bones or rig properties, so hiding the meshes does not help. I noticed that you found the button for disabling drivers, but unfornately that button does not work wiith the new morph system yet.

So the best advice I can offer is only to load the morphs you need. Of course, there is a trade-off since you might not know in advance which morphs you will need.

[engetudouiti]

Though it seems not directly relaated with this issue, When I convert rig to rig-fy, now I everytime get this error,

then mesh not change vertex group for the armature rig = rig only move.

I test rig-fy to show current MHX rig problem (IK foot is really strange now) , but I can not show it with mesh for this error

location: <unknown location>:-1
Error: Python: Traceback (most recent call last):
File "C:\Users\TAKE\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\import_daz\error.py", line 247, in execute
self.run(context)
File "C:\Users\TAKE\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\import_daz\rigify.py", line 1272, in run
gen = self.rigifyMeta(context)
File "C:\Users\TAKE\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\import_daz\rigify.py", line 863, in rigifyMeta
self.rigifyMeta1(context)
File "C:\Users\TAKE\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\import_daz\rigify.py", line 1105, in rigifyMeta1
self.fixBoneDrivers(gen, correctives)
File "C:\Users\TAKE\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\import_daz\fix.py", line 165, in fixBoneDrivers
changeTargets(rig, rig)
File "C:\Users\TAKE\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\import_daz\fix.py", line 160, in changeTargets
self.changeTarget(fcu, rna, rig, assoc)
File "C:\Users\TAKE\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\import_daz\fix.py", line 189, in changeTarget
trg.bone_target = assoc[trg.bone_target]
KeyError: 'foot.L'

So now I can not convert G3 for rigi-fy.. I test with some options, (but not import any morphs) can you convert G3 to rig-fy without this error?

Ah ok though I can not solve this error, but not directly cause problem to posing.

Before I remember, rig-fy auto set IK when generate rig. now I need to set rig as IK manually about add on generate Rig fy. (it start as FK rig) but it can still pose. (I do not know it relate with option I can not find any option to decide start as IK or FK)

if I ganerate rig-fy from meta-rig, (no use add on convert), it start as IK rig as same as before. I suppose the error cause this issue.

[Domiek]

Hi Thomas, yes everything is properly disabled rather than hidden. I’ve taken it one step further and deleted everything other than the rigify armature and the lag persists at 15fps. Removing all morphs and drivers did not resolve this issue. I imagine there is some sort of conflict going on so I’ve started a fresh import process to check FPS impact at each step.

Merge Rigs → Eliminate Empties → Add Extra Face Bones → Morphs section
8.1 Char, everything disabled but armature

‌

‌

Import Standard FACS + Visemes: 22 fps

Import default FACS Expressions: 21 fps

Import JCM’s: 18 fps

Import Flexion: 18 fps

Re-Enable Base (16k poly) Figure Mesh: 15 fps

‌

What is the proper procedure here if I want to take advantage of FACS, JCM’s and Flexions? I don’t mind working with shapekeys on the mesh itself, rather than the convenient and well organized Diffeo window if it means better performance. As you can see, there are no luxury morphs loaded, these are only the base essentials for using FACS + standard JCM’s. Am I approaching this incorrectly?

[Alessandro Padovani]

I don’t experience any lag here. If I hide the mesh G8.1 runs at 30 fps. If I unhide the mesh it runs at 15 fps with simplify enabled. I have a ryzen 2200G for the viewport so it’s pretty weak.

Test scene and import options included.

‌

‌

‌

[Alessandro Padovani]

basic scene for fps test, it's a G8.1F with basic wear and hair

[Domiek]

Thanks for doing the test any providing the file Alessandro. Based on your screenshot, it looks like you don’t have any of the FACS units loaded, correct? Without FACS I’m also getting full fps. Is it not possible to utilize FACS without lagging the rig?

[Alessandro Padovani]

Tried with facs instead of expressions and I get 30 fps here.

‌

[Xin]

Works for me too (with everything that you listed imported with the normal import, not the easy import). One of the problems could be that you are not disabling the subdivision. When you say above that you disabled the figure, you still have its collection enabled, check the other screencaps to see the difference.

I get 24+ fps on a laptop even with the figure visible with subdivision off. The subdivision is the only thing that causes the slow down.

Check your other addons too. There are some really invasive/buggy addons sometimes.

Also, check your Blender version. Try using the stable release.

[Domiek]

As provided by the screenshots, everything is disabled, not hidden. Even several tests with everything in the scene deleted aside from the rig. Something is happening that is not obvious to me. As you say, it could very well be a conflict with another addon but my Diffeo Genesis 3 projects from last year are working without any lag. I just realized I forgot to mention that this is done with the HD Export from Daz, if this makes a difference.

I’ve just once again imported the g81-basic that Alessandro provided. Imported Visemes, FACS Units, FACS Expressions, JCMs and Flexions. Everything disabled but the rig, 24fps (I set FPS to max at 24 so this is ideal). I then re-enabled just the Gen 8.1 mesh with multires disabled, 15fps.

‌

Here comes the interesting part. Disabled the mesh once again and only having the armature enabled doesn’t resolve the lag. 16 fps

‌

Now even more interesting, entirely everything deleted but the armature. 16fps

‌

Removing Standard Morphs from the rig brings the FPS back to 24.

‌

‌

I’m not understanding what this could be. When you guys test the rig, can you pose and disable/re-enable the mesh to see if this sort of issue triggers for you as well? In the meantime I’ll disable all addons and try again.

‌

Thanks!

[Xin]

I don’t get that problem either. Try disabling the mesh collection, not just hiding them from the viewport. It’s the first checkbox on the collection’s name what you need to disable. In any case, It should work anyway with the figure visible as long as you disabled subdivision. Seems like it’s some other addon to me.

[Domiek]

I’ve isolated the issue to be in developmental build of Diffeo. Version 1.5.1c has no issues and I can pose a subd0 mesh at full fps with FACS Units, FACS Expressions, Visemes, JCMS and Flexions imported.

[Xin]

1.5.1 uses a different driver system that had a lot of issues and limitations. The current version uses Blender’s native drivers and properly implements FACS (1.5.1 only supported FACS partially), so it’s not a good comparison. The current version is nowadays better in every sense (including performance since it doesn’t execute the drivers on Python).

The issue is still on your end due to some addon you are using, due to your Blender version or due to some other reason.

[Domiek]

The latest tests were done on 2.92, no addons other than Diffeo experimental build ebbae5d95dd2

‌

‌

‌

‌

[Xin]

I tried 1.5.1c and I lose around 3 fps with the old system, even when the newer system is executing way more stuff since it properly implements FACS.

I have no idea what could be causing your issue. What kind of CPU do you have? have you tried resetting Blender’s settings (backup your current settings first)? also try resetting the addon’s settings.

[Buddyspencer13]

Hi there guys, as an average user who uses this plugin quite a bit, this is interesting and I wanted to share my tests here as well, on the other hand I think Domiek has something wrong with his scene ;

I have imported Genesis 8.1, in version 2.92 and with the latest version of the plugin, I have tested these settings on a basic animation consisting only of moving the arm and playing it in the preview, according to my tests, I get these rates with Ryzen 2700x :

Visemes seems to decrease performance somewhat, while Expressions decreases performance even more considerably, much worse, so to speak, what can this be due to? Blender CPU limitations, Blender OpenGL limitations? the complexity of the drivers? otherwise I think this implementation is quite good and compared to the previous version I also noticed an improvement here, on the other hand, if this gets more optimizations it will always be appreciated. Also it would be interesting that both simulations and drivers could be accelerated by the GPU in the future or in the 3.0 version of Blender and be able to do these tests.

Thanks Thomas, Alessandro, engetudouiti, Xin, for your work.

[engetudouiti]

If Thomas can limit morphs, only which user must need, I suppose some commit could be avoided. (of course it only effect FPS) eg,, Xin offered way (not use custom function) is actually make peformance more better.

But some commit which tried to make all Facs morphs work correctly may need not.

I think if Thomas can decide which morph he should import , as future,, if he can offer best peformance option (like setting preset) but if make so, We need to accept, we can not import complex morph any-more with the setting even though it is default daz offer morphs., and user can not choose which morph will be imported. (or you can import, them but it not work correctly after all) some Facs morph or MCM type controller may not work as same as daz anymore. But I think the option may need.

One thing I hope if Thomas can test is, try to add raw props as rig.data prop, because most of all props now attach to rig.data At current only law prop attached to rig (object). The reason Thomas need to make it so , without it new driver not work with some case. But it seems solved by use update tag then I do not know if we need to attach prop to rig.data still or not. if use rig.data, I suppose we can attach raw prop for rig.data too.

I do not know how depthgraph or BVH tree work . but I expect, if attach raw prop to rig.data, it may get better peformance, (rig object or rig.data) but do not know actually it effect FPS or not. As you know Thomas is only one who can maintain and improve it,, so if there is user who have clear knowledge about these issue and can help him, this add on can be more better. Or if there is reason Thomas must make it so, (I do not know)

[Domiek]

Xin, I’m on a Threadripper 1900x. Resetting Blender settings didn’t change a thing. I ended up downloading Blender 2.93 Alpha and there are some interesting observations

‌

• Using Diffeo to import a new char on 2.93 results in zero lag. Rig + Base Mesh + all FACS/Morphs listed previously results in a solid 24fps
• Importing a character via Diffeo in 2.93 and loading that blend file into 2.92 results in the same solid 24fps
• Importing a character via Diffeo in 2.92 and loading that blend file into 2.93 results in that poor 15fps described earlier

Did the upgrade to Python 3.9 in Blender 2.93 do something? Was resetting settings and disabling addons in 2.92 not enough and I had something conflicting on my system? Was there some other reason and I’m just a special case?

No idea.

‌

[Domiek]

Imported in Blender 2.93 and opened in Blender 2.92.

‌

Imported Visemes, FACS Units, FACS Expressions, JCMs, Flexions, and 3rd party body morphs + merged NVG8 anatomy. No FPS drop on the rig.

[Alessandro Padovani]

Domiek, Spencer, here I don’t seem to get much of a difference with or without facs and expressions. I mean, the rig alone always runs at 30 fps no matter what. Then when I turn on the geometry I get from 12 to 15 fps depending on the imported features. With simplify to avoid subdivision.

By facs I mean the full set facs + facs expressions. By expressions I mean the full set units + expressions + visemes.

Tests done with g81-basic.duf, daz studio 4.15, blender 2.92, diffeo 1.6. I have a ryzen 2200G for the viewport that’s a weak apu.

‌

‌

[Steven Aston]

@Domiek This is not a problem with the diffeo plug in, but blender itself. Its an issue with threadrippers/ high core count CPUs in versions after 2.83. I have already submitted a bug report to blender and they are working on it.

Take a look at this,

https://developer.blender.org/T86658
you can verify by opening the gen 8.1 file in 2.83 LTS and see if framerate improves. Or disable some CPU cores to get better framerate in 2.93.

‌

[Alessandro Padovani]

That also may explain why 1.5 works fine. Because, if I understand correctly, 1.5 uses python to compute expressions, while the new 1.6 system leaves that to blender c++ for multithreading, that in this case gets the bug for high-end cpus.

And mine works fine because it’s slow, that’s also funny.

[Buddyspencer13]

engetudouiti, I have no problems with this implementation, as I comment this in general works quite well for me and has a good performance in general, using my first configuration that I put in the images is fine for me in Diff 1.6. in Blender 2.92 Stable or 2.93 Alpha, I think that + 40 fps is good to animate in my case, having all the morphs applied in each category, in Face Units, Facs Units, Facs Expressions, although I like to animate at 50-60 fps, but it's fine, another thing I forgot to comment is that you can also choose which expressions or morphs to use when exporting the morphs for the face, using not all, some specific in each category, improved the performance somewhat more, this always did it with version in 1.5.1 with Face Units for example, I will put an image below doing this in 1.6 ver. So in general, as I say, I notice a better performance in everything in general, and in the image above all morphs of each category are applied in each configuration.

About the other, I can't give an exact opinion or what could be better here, but for me it's fine what is already done for now, of course any improvement would be fine and I you guys can find ways to improve this, or Thomas can improve things in the future, will be great, as he has done with everything in general with the plugin, I still find it amazing the amount of features and what is to come for this plugin.

Regarding what you say, what I would like is that Thomas could make a kind of saving config or presets as well, for the morphs, something like you mention, for example, of the face in each category, this in case the user wants to save a list of morphs chosen, for when one loads a new model, can apply a specific configuration or a stored selection of selected morphs.

‌

Alessandro, i see, in my case, when loading all morphs of “Face Expressions”, the performance worsens a lot, even when testing only a few selected ones and not all of them, see ;

‌

[Domiek]

Steven Aston that’s an interesting find, thanks. Unfortunately that doesn’t seem to be the key issue here since importing in 2.93 and loading back in 2.92 results in no fps loss.

[Noname]

I will add additional info to this, as I did testing on my end:

Spec:

• TR 3960X
• 32 GB RAM CL 14
• RTX 3090
• NVME OS & blender
• SSD blend and daz files
• display 60Hz
• Windows 10 P 1909

Blender 2.93 alpha april 09 + diff.162

Steps:

• imported G3F LIlith using Easy Import with all morphs and merge rigs
• use default animation playback 24FPS

Testing after import:

Press space - playback FPS 24

Testing “animation”

Go to Body Morphs and add key frame (via right click “Insert keyframe” or I shortcut) to any random morph.

Press space - playback FPS 8

At this point I hidden and disabled in viewport all meshes except for main body mesh (without hair) and changed subdiv to 0.

Deleted key that was inserted above (no animation, no keyframes).

Change animation FPS to 30 FPS

• Press space - playback FPS 34 (constant, not ok should be 30!)

Change animation FPS to 60 FPS

• Press space - playback FPS 103-120

Change animation FPS to 120 FPS

• Press space - playback FPS 59,9 - 60 (occasional spikes to 120+)

Change animation FPS to 240 FPS

• Press space - playback FPS 59,9 - 60 (occasional spikes to 120+)

Changing Blender core affinity (without closing blender !)

To do so go to Task Manager → Details→ find Blender → right mouse button and choose option Set Affinity

Set numbers of threads (keep in mind 1 core == 2 threads).

I set mine to 8 cores 16 threads:

Change animation FPS to 30 FPS

• Press space - playback FPS 30

Change animation FPS to 60 FPS

• Press space - playback FPS 60-61

Change animation FPS to 120 FPS

• Press space - playback FPS 59,96

Change animation FPS to 240 FPS

• Press space - playback FPS 59,96

Set affinity to 8 threads, even so 0 - 2 - 4 - 6 - 8. The goal here is to pin Blender to main thread not HT one (with is up to 30% of “real” thread performance).

Will skip FPS, more or less as above.

Do animation, I used moho file and added some key frames for body morphs, changed animation duration to 60 frames. Set FPS to 60.

‌

Set affinity to all cores:

• Press space - playback FPS 32.6 - 33.6

Set affinity to cores 0 → 3:

• Press space - playback FPS 34 - 35 (fluctuates between)

Set affinity to cores 0 → 7:

• Press space - playback FPS 35 (fluctuates between 35 - 36, some drops to 34)

‌

Saved animation, rebooted to Linux (Debian 10.9, kernel 5.4.0-0.bpo.4-amd64):

Blender 2.93 April 11 - no plugins, all default after download.

‌

Change animation FPS to 30 FPS

• Press space - playback FPS 30

Change animation FPS to 60 FPS

• Press space - playback FPS 39-40

Change animation FPS to 120 FPS

• Press space - playback FPS 39-40

Conclusion - Windows vs Linux → Linux + 4 - 6 FPS

Deleted all key frames - same as above

Deleted all key shapes - same as above

Skipped tasksel for core affinity test.

NOTE: I will try to compile Blender using custom optimization levels (O2 vs O3 and with additional CPU specific optimizations, i.e. avx2, sse etc.). Most probably performance increase will come from O3 optimization. But I will do this next weekend.

[Alessandro Padovani]

@Domiek said “importing in 2.93 and loading back in 2.92 results in no fps loss“

Doesn’t that mean it’s a blender bug in 2.92 ? Then on my side everything works fine in 2.92, and I have a basic apu. So perhaps is something related to high-end cpus as Steven reported, even if it may not be the same bug.

Then does it work fine in 2.93 for you ? If it is so then everything will hopefully be fixed when we switch to 2.93.

[Domiek]

@Alessandro Padovani It may be a blender bug but I'm thinking it’s not the same one because that bug is listed as being present in 2.93 as well, which has no issues on my end. If I understood that bug correctly, I should be experiencing similar lag regardless of which diffeo version is used to import the char, which is not the case.

This could also not be a bug at all and simply something wrong on my end. Either way, I’m using 2.93 as a workaround which seems to be going without issue.

‌

[Steven Aston]

@Domiek

Steven Aston that’s an interesting find, thanks. Unfortunately that doesn’t seem to be the key issue here since importing in 2.93 and loading back in 2.92 results in no fps loss.

This is because the bug is already being worked on and they have begun patching it. In the early versions of 2.93 the bug was present, performance has gotten better as they are patching it but its still not fully solved. So unless your using an early build of 2.93 you will see an improvement over 2.92.
What you all need to keep in mind is that it does matter where a file is created, IE with which version, as everything is stored in the blend file itself and not in the blender version. So if you create an armature and add drivers, the evaluation for those drivers is all stored and handled in the blend file itself. This is how you can open a blend file on a portable version of blender on a random computer and everything works fine. This is also what makes it compatible with multiple versions of blender, as its not dependent on the version since everything is stored and run from the saved .blend itself. So if you create any armature with versions 2.92 and open it with any version of blender, it will have the CPU bug. If you create it with 2.83 LTS it will not have the bug. With 2.93 it depends on what build you have, IE how far along the fix is.

to the no name user, changing the affinity has no effect on the bug since the cores are still visible to the scheduler. you have to disable cores in the bios to see real difference.

[Domiek]

Thanks Steven, I wasn’t aware that this is how blender files work and what you say does seem to align with the results. What I’m not understanding is why I don’t experience this lag when using earlier versions of Diffeo. On Blender 2.92 and earlier, I’m experiencing full fps on Diffeo 1.5.1 where this cpu should still be in effect, no?

[Steven Aston]

@Domiek this is where Alessandro’s explanation comes in

That also may explain why 1.5 works fine. Because, if I understand correctly, 1.5 uses python to compute expressions, while the new 1.6 system leaves that to blender c++ for multithreading, that in this case gets the bug for high-end cpus.

Its sort of confusing, but think of it this way. When you create drivers in blender, it writes to the blend file how to evaluate those drivers. (Im no programmer or python expert this is just an over simplified example.)
So eval drivers = system default so now if it was created in 2,83 it works fine, if it was created in 2.90 or later the evaluation is subject to the CPU bug. so in this case where the file was created matters.

When using an add on however like diffeo they can call specifics for evaluation.

so if diffeo 1.5 says

eval drivers = python/legacy then it will specifically use the old system for driver evaluation regardless of what version you are creating the file in, even though the system default has a bug its bypassed in this case since the add on calls for a specific evaluation system. This then gets stored in the blend file so in this case it doesnt matter where the file is created.

and if 1.6

says eval drivers = C++( IE new system default) then it will be subject to the CPU bug.

and I believe he was using python for the evaluation up until now for compatibility with 2.79. ?? So the CPU bug only became apparent to diffeo users as of 1.6.

So apart from waiting for the bug to be fixed, you have 3 options. Either disable CPU cores when animating/playing back. Use an older version of diffeo to import the character. or use 2.83LTS(assuming 1.6 works with 2.83)

‌

[Domiek]

Hi Steven, thank you for the explanation it did help me understand a bit further. It seems that I will have to reimport all my characters once again in the future since this is a long term project. At least 2.93 makes this situation somewhat useable until the bug is fully patched.

[Noname]

@Steven Aston

to the no name user, changing the affinity has no effect on the bug since the cores are still visible to the scheduler. you have to disable cores in the bios to see real difference.

I don’t know about the bug but it does change FPS for me. Affinity does exactly that pins process to specific cores. IMHO as long as process don’t spawn new processes (with blender doesn’t do, at least for animation) setting affinity does work exactly as disabling cores in BIOS - it’s just per application feature and scheduler takes that into account.

In example - this is how pinning application to non HT (ones that have up to 30% efficiency) cores works.

‌

Do You happen to have task link | number to issue with driver and FPS ?

Also for anyone interested in animation - Amazon AWS contributed grant to Blender for animation specifically and this effort will kick in in the middle of this year so I suppose starting from Q3 we will see some nice improvements to the animation subsystem in Blender.

‌

‌

[Xin]

I opened #461 with an implementation that improves performance on the legacy non-FACS Expressions (and legacy Units too), which seemed to be causing issues for some people/cpus.

As a side note, if you are really running into a lot of FPS issues, you can tell Blender to drop frames:

‌

[Xin]

Also, I can confirm that what Noname says is right:

In example - this is how pinning application to non HT (ones that have up to 30% efficiency) cores works

In my case, with Blender 2.92, using the odd numbered cores results in a gain of 5 fps in certain circumstances.

What happens in the following:

• You load Expressions (the legacy ones, no the FACS ones).
• You run the animation the first time and everything seems right.
• Then you change a slider and immediately reset it back to zero.
• Running the animation again results in a loss of around 5 fps, with nothing having really changed.
• Changing affinity to exclude the even numbered cores brings the performance back.

‌

[Steven Aston]

@Noname When I reduce the core count using task manager I get a decrease in CPU load obviously, but the FPS is never as high as with them disabled in the bios, as the bug is still there. My guess is because it sees 128 threads on start up, and configures itself for that. So even giving it less access via TM still runs the faulty code. Im also assuming its much worse on my system vs yours because of the additional numa node.

Do You happen to have task link | number to issue with driver and FPS ?

Was this directed at me? if so, what are you referring to?

[Noname]

@Steven Aston Did You checked CPU clocks in both cases (disable in BIOS and via affinity in TM)? I think reason why You do see higher FPS via BIOS disabling is due to that. Maybe also internals of Zen2 and cache access (L3 sharing to 4 CCX vs 1 when disabled in BIOS ???). I seen on Blender bug page that You already checked NUMA.

‌

Basically people complain about 2.8+ branches and performance issues comparing to 2.7. Mostly around Ui area - responsiveness of app. This was mentioned also in Blender Today (podcast with Pablo), Also there is many areas in Blender that are simply ST and simply higher clocked CPU wins (yes I know this is not direct issue that we are talking about here).

You did also mentioned that setting affinity reduces CPU - this is direct proof that code is not executed on other threads. I doubt that Blender configure itself on startup to threads available - what If You mine using 16 threads after starting Blender - those are 100% utilized? This would be also bad design and I doubt that Blender uses this king of low level code to handle threads, I think they move this to OS to handle.

‌

Unfortunately I don’t know what could cause situation on Your end (BIOS vs TM affinity), but I can end on more optimistic note - Blender due to AWS grand will hire dedicated dev to handle animation so I’m guessing this will also cover improvements in viewport update for animation.

Task link - yes this question was for You, but I did found task that You talked above so You can ignore it :).

‌

‌