Gui thread , cpu rise

gentleclockdivider · 2025-07-03T18:38:12+00:00

There was an error rendering this rich post.

So this is troublesome
I created a simple instrument using the sinebank and iteration .

The iteration is triggered using the gui out

The multidisplay is set to bars , cpu usage is around 8%

By just adjusting the space betwee the bars , the cpu usage for the gui thread increases considerably shown in windows taskmanager , so bad that my host becomes laggy .

Even in reaktor standalone
Just decrease the value of "space"parameter to 50 , and you will notice the lag

sinebanker-2.ens

Here's a giff , notice the cpu usage in taskmanager after i decrease the width of the bars
This is troublesome
The sinebank has nothing nothing to do with it , you can safely delete and the issues is still there
I suspect it's the snapshotarray ( for storing the multislider data ) that can't handle it

https://i.imgur.com/TEk9gJx.gif

I dumbed it all down , deleted everything except the iteration and the multislider
It's still there , just move the slider and notice the lag ( set space between bars to 0.5 )
Even deleted the snapshotarray , so the iteration is controlling the multislider directly at gui rate

This is a serious bug I think , only 128 elements and by just adjusting the space between bars the cpu increases drastically ( i the gpu thread )

Trouble.ens

https://i.imgur.com/ebVAo4h.gif

Find more posts tagged with

Comments

gentleclockdivider

No one ?

Just try the provided ensemble and set space to 0.5 or lower and watch the cpu in your taskmanager

PoorFellow

https://community.native-instruments.com/discussion/comment/233135#Comment_233135

Nothing really conclusive on my computer. Yes in 'idle' it uses % 0.5-0.7 CPU and it does rise to around % 5 , that's around a factor 10 , but that was for a couple of minutes then it dropped down to not much more than % 1 . (P.S. On consecutive attempts the numbers are the same only it appear to not drop again - at least not as fast)

As you most likely already knows then I don't know that much about Reaktor so I can not say why it behaves as it does. Also then my computer is not exactly weak (I upgraded my rig last year and now use a newer Intel i7 and got plenty of RAM so it might have been much worse on a lot weaker system.)

Reference the 'Trouble.ens'

PoorFellow

https://community.native-instruments.com/discussion/46387/gui-thread-cpu-rise

P.S.

This appear to be a problem regarding updating screen graphics or something (?)

Try the following : Have the GUI being at the top window , then try dragging the programming window up so that it covers the interface as shown below here and you should see the CPU use drop instantly. This might not solve your problem but at least it's a step closer to understanding it.

gentleclockdivider

The issue is that the gui becomes extremely sluggish because of cpu usage that is not reported by reaktor since it's not happening in the audio thread , the triggerng of the iteration is done by the display clock ( whcih is verry modest )

When the iteration is triggered from event rate clock , the cpu rises in the cpu readout ( as expected ) but it's not laggy at all .

So I guess there is more happening under the hood as we know it , and all because of redrawing some boxes

Weird , verry weird

colB

I was able to replicate the issue. Not sure its a bug though. More like very old code that doesn't handle certain cases well at all.

Worth reporting, but not sure there will ever be any fix, there are other more serious bugs that are actual crash bugs that have been reported since many months, and still persist.

Definitely very annoying if what you need is the settings that cause slowdown though.

Setting the iterator to throttled mode with a 4000 per second limit seemed to help a bit, but again that will be context specific.

gentleclockdivider

This is worrying to say the least , the fan of my laptop is spinning like crazy when using modules that are 2 decades old ( multidiplay not even using antialiased lines )
Something is def. not right and I suspect a bug has slipped in
Just notice the incredible rise in cpu when switching between panel A-B , one of which has the dread multidiplay , I also move a knob's position on screen and that the real lag you're noticing ( recording it at 24 fps )
Please N.I . fix this

https://i.imgur.com/yIaIJF0.gif

Guicpu.ens

KoaN

https://community.native-instruments.com/discussion/comment/233930#Comment_233930

You could program it so it only updates on a knob change "using the mouse area module for example" instead of the iterator functionning 100% of the time on the DClk,well unless you need the display to move all the time. The iterator going into X1 multidisplay seems to be the culprit.

colB

https://community.native-instruments.com/discussion/comment/233930#Comment_233930

Please N.I . fix this

There's no point in this, the folk that matter are not listening here, as of the past few years anyway ;)

They stopped responding on the Reaktor beta portal long ago, and that seems to have been wiped (although it might just have been moved and me removed from it)

The only way to report an issue is to raise a support ticket.

FWIW, there are bugs that cause crash to desktop that have been reported long ago and still not fixed, so good luck with this that could be argued as not a bug (I agree with you that it probably is one)

Quick links

Unanswered questions