Gui thread , cpu rise

Options
gentleclockdivider
gentleclockdivider Member Posts: 356 Advisor
edited July 3 in Reaktor

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

1.jpg
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

Comments

  • gentleclockdivider
    gentleclockdivider Member Posts: 356 Advisor
    edited July 4

    No one ?

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

  • PoorFellow
    PoorFellow Moderator Posts: 7,361 mod
    edited July 4
    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'

    image.png
  • PoorFellow
    PoorFellow Moderator Posts: 7,361 mod
    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.

    image.png
  • gentleclockdivider
    gentleclockdivider Member Posts: 356 Advisor

    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
    colB Member Posts: 1,122 Guru

    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.

Back To Top

Categories