BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Author Topic: EVE screen designer cpu use  (Read 147 times)

Cyrilou

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
EVE screen designer cpu use
« on: May 20, 2022, 03:56:04 PM »

Hi all,

When ESD is running and rendering UI elements, Emulatorprocess.exe is using 100% of the CPU. Can you reduce that? I think your QT main task doesn't use sleep function to authorize idle time for other tasks.

Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 570
    • View Profile
Re: EVE screen designer cpu use
« Reply #1 on: May 23, 2022, 12:13:36 PM »

Hello,

Thank you for the report, i will pass this back to the ESD development team to see if they can make improvements and reduce the CPU utilisation whilst running the emulator.

Best Regards,
BRT Community
Logged

Kaetemi

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: EVE screen designer cpu use
« Reply #2 on: June 14, 2022, 07:46:13 AM »

EmulatorProcess runs the emulator and the user code. Any unusual behavior in your code?
It should normally throttle down by itself already when there are no frame changes being rendered.
The process also runs on the lowest priority by default, so it should only have minimal effect on any other processes regardless. The highest usage will be while recompiling the code.

(If you happen to be running giant ASTC animations, that's the only case on the emulator that's not well optimized, and you might see high usage.)
Logged

Cyrilou

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: EVE screen designer cpu use
« Reply #3 on: June 14, 2022, 04:31:45 PM »

EmulatorProcess runs the emulator and the user code. Any unusual behavior in your code?
It should normally throttle down by itself already when there are no frame changes being rendered.
The process also runs on the lowest priority by default, so it should only have minimal effect on any other processes regardless. The highest usage will be while recompiling the code.

(If you happen to be running giant ASTC animations, that's the only case on the emulator that's not well optimized, and you might see high usage.)

I'm ok with that, I have UI elements that does not use cpu ressource. But I've noticed that widget ESD_MultiGradientRounded use 30% of my CPU. Why?
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 570
    • View Profile
Re: EVE screen designer cpu use
« Reply #4 on: June 15, 2022, 04:20:11 PM »

Hello,

The multiple gradient calculations used with ESD_MultiGradientRounded are computationally quite intensive as the widget includes 4 separate colours which require blending, as such the emulator will use some extra CPU resources when displaying this widget on the screen. Note: EVE does not include a frame buffer and for each screen refresh (based on the LCD settings used, normally between 30-60 fps) every pixel on the screen must be calculated, the emulator operates in the same fashion where the screen is calculate for every refresh. This may account for the higher CPU usage you are seeing with this given widget.

Best Regards,
BRT Community
Logged

Kaetemi

  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: EVE screen designer cpu use
« Reply #5 on: June 20, 2022, 10:46:18 PM »

I'm ok with that, I have UI elements that does not use cpu ressource. But I've noticed that widget ESD_MultiGradientRounded use 30% of my CPU. Why?
The emulator has a detection to not redraw the screen if it's presented the same display list twice without changes to graphics ram.

The multi gradient works by writing four colors to a circular bitmap buffer with 64 entries, giving you 32 gradients per frame.
This technique causes a change to graphics ram each frame, which causes the emulator to do a full redraw.

A solution would be to cache the last couple of gradients in the library, and re-use when possible. That'll also let you draw more of these fancy gradients when they share the same colors. :)
Logged