AC App Best Practices and Framerates

[Esotic]

@FWallner @Topuz @Akis @Minolin

I'm attempting to loop in some of the "top" coders for AC apps that I (and lots of other folks) are using. I've been mulling over some ideas lately and wanted to see if anyone was interested in providing feedback or coordinating on implementation.

I personally tend to write very specific apps that do a singular thing (hopefully well). I've also been obsessed with frame rates lately and have been trying to find ways to minimize the FPS hit of using my (and other folks) apps. I finally got around to "borrowing" some code from PitConfig to realize when an app is visible or not (turned on from the apps toolbar) instead of just always running in the background. That's going to help for all my apps that don't need to process data while off-screen, but I'm also wondering about possibly having the apps run in a "low power state", and would like to have some way to get several apps to all toggle between "low power" or "regular power" on-the-fly with a singular button push, like how you can hide/unhide apps wth CTRL-H. Maybe using something like AutoIT to trap the keypress and a shared INI that lives in the main AC folder that the apps can poll/hook to get the current low/regular state?

Does anyone else think this is worth pursuing? Any other ideas for minimizing the FPS hit of using an app in AC? Has anyone been testing/upgrading their apps in VR to minimize the FPS hit? I do not personally have an HMD (not sure I can justify that expense yet), but more and more folks are using them every day, and I've been told apps in VR result in a pretty big framerate hit.

Cheers,

Dave\Esotic

 

[Topuz]

Well, to begin with, Python is not a very efficient language, especially not for realtime applications like we use it. Plus we (I?) have no idea how the app drawing actually hooks up to the rendering queue.

Honestly, besides the usual programming practices like creating timers, making sure your loops are ok and your code only executes as often as it's actually needed, avoiding disk writes during runtime, I haven't really dug too much into optimization of AC apps. What I've noticed in practice though, is that labels are a major (probably single largest) CPU hog. For example, Sidekick has two "slave-apps", which don't really do anything besides showing a bunch of labels, checkboxes and spinners for customization. With only Sidekick (the main app) visible, CPU time increases by 5%, once I turn on the settings sub-app, it adds additional ~25%. Static labels, absurd, but obviously the way they're drawn is very CPU intensive. For that reason alone, Sidekick is substantially less CPU heavy than RaceEssentials (Sidekick has ~1/3 the amount of labels compared to RaceEssentials), although the code running behind is quite similar. With stuff like this present, I really had no wish to dig deeper into optimization since the point of the entire effort would be questionable.

The app logic however, I had no trouble with. The GL drawings proved very cheap on the CPU (no choice but to draw with every frame, so that's good), and the amount of calculations I need in my apps was never an issue. Although, there are devs (Neys is one of them), who chose to split the app and do the heavy stuff in the separate *.exe process.

@Minolin and @Neys could tell you more, pretty sure they have substantially better programming knowledge than myself.

 

[Esotic]

@Topuz Now I'm going to have to dig into that Sidekick code. ;p

I was just thinking about making extra windows/apps in AC to offload some of the controls, or to make a "lighter" version of the data being presented. I have noticed that only updating labels/controls when the underlying value has changed (as opposed to updating it on every frame) is more efficient, but now I'm wondering about using GL to draw the text (maybe too much dev require to make that feasible). I'm also wondering if transparency on controls/windows affects how much processing is required when displaying an app in AC.

I do like using python for AC apps (mostly from a philosophical open-source perspective), but I've also been wondering if a compiled plug-in would be inherently faster. These all seem like good questions.

 

[Stereo]

My odometer app is entirely GL textures, I've never looked at its performance impact though (by default it's about 20 textures per frame, I think you can adjust the number of digits).

My understanding of the loops calling apps is that it calls the functions sent it by addRenderCallback of each app, gathers a set of draw calls, and then when graphics is ready, passes that whole lump to whatever adds them to the frame (if any app crashes during this time, the lump doesn't get sent at all, so apps can have interesting effects on each other - eg. my odometer would blink at the start of each lap because some other app was failing to complete its render call on the step when lapcount updates).

It just runs acUpdate once per frame without regard for the graphics pipeline. So anything that takes some cpu time should go there to avoid affecting framerates, the onRender should just be minimal amounts of stuff to update the app visually.

I assume by some means the rendercallbacks of hidden apps are removed from the list, haven't poked too closely at how that works.