Since my CPU performance for my simulator in iRacing is one of the bottlenecks I watch out for tools using up too much CPU time. I noticed that having Simucube 2 True Drive window open will use up to 6% of a i9 10900K @ 5.2 Ghz CPU - just for sitting there doing nothing?! How is that possible?!
I don’t use wireless wheel and I don’t “use” do anything with it. Just when the window is open and shown it will draw a ridiculous amount of CPU power (in my opinion for what it is and does).
In contrast - when I minimize the window (so everything runs like before, just the window is not shown), there is no noticeable CPU usage whatsoever?!
I am kind of bothered by the way programms nowadays “waste” CPU power - because I guess they are supposed to be that fast and powerfull anyway.
I guess there should be a huge potential of improving this behaviour…
The current version is 2021.8
I am only getting 3% cpu use and only when on the tab you show above with the wheel image.
If I select any other tab the usage drops to near zero (It’s bouncing between 0% and 0.2% as I write this.)
Well, I think that’s the tab/screen it opens with automatically, isn’t it? At least when it gets started on my system it opens like that and normally I’d leave it like that.
And I consider 3% not “only”. I mean consider the computing power of modern CPUs and what 3% of that actually means!
Also I run up to 20 tools while racing - if all of them need “only 3%” for basically just being active, that’s most of the CPU power and nothing is left for the actual simulation…
I do believe that there should be a significant improvement possible.
Not sure why QTLibrary TD is using makes simple rendering task like this so expensive. It was brought up before, I think Mika lowered refresh rate to 30fps but even with that it’s pretty expensive.
One option is just to ditch that customizable animated gif for standard slider control like MMos. Or still keep unanimated custom wheel image (for “personalization”) with slider under.
With that 3% I wasn’t trying to justify it, was just saying mine was lower than yours, and also wanted to point out that the other tabs aren’t doing it. I tend to leave mine on the profile screen, especially now with Paddock’s online marketplace of free profiles to try.
You mention that on your system it’s opening to that screen.
In the folder with truedrive, there are a few readme files that might also help.
In "tray_icon_and_command_line_instructions.txt
There are instructions to get true drive to start automatically in the system tray with a minimized UI.
Again not saying the 3-6% on that screen we’re seeing is right, just raising awareness of the workarounds that exist today.
The source for the CPU consumption is indeed the updates in the UI. But they have been implemented in such was for a long time already, that when the True Drive window is not the active window or the tab with the wheel image is not the active tab, CPU consumption will be much reduced. So when people do not usually have the True Drive first tab open when driving, the CPU consumption of that dialog update code really does not matter too much.
Because I use plenty of different simulations and steering wheels and swtich several times a day. And every time I have to choose a different profile and/or havee to re-center the steering wheel. So I keep the tools necessary to switch between simulations and steering wheels open on an extra screen.
At least I did until I figured out how much CPU TD needs just to be open (on that tab).
Having it opened minimized might work for our standard simulation/steering wheel configuration, but since I have to switch a lot it would be nice to be able to keep it open, like most other tools too. And I tend to double check settings before starting anything.
Just because some do not use it that much does not mean there is no need for optimizing/improvement. Especially when it’s that obvious that something is not working very well. Also since there is a special features to implement customized steering wheel images (and by the looks of the GUI implementation that’s quite some code).But when actually showing the wheel it takes such a hit on CPU?! I would rather opt to update the code to make it CPU efficient if a customized steering wheel feature is something needed, or ditch the whole feature all together in order to avoid this issue in the first place…
I am fighting various performance issues because too many programms and tools work like that, just implementing features without proper testing of the performance effects. Each by itself is not a huge problem, but running 20 of them together is. Therefore I try to point out when I come across stuff like this.
I agree. It’s definitely not my nor anyone elses place to tell you how to use software and I hope that your detailed explanations will help the granite team see the impact it’s having on you. With a little luck maybe Mika will come up with some solution when he’s out for a bike ride - often that’s the way our brains work - but he can’t think about it if he doesn’t know it’s an issue for users so you’re doing the right thing to bring this up.
Thanks for the feedback. But I must reiterate that when True Drive is not the foremost window, the update rate is reduced so this whole thing becomes a non-issue.
I accept your decision, but I think I made a point why it is an issue for users who
has to switch a lot between profiles/wheels/simulations and have to use TD multiple times
users who actually want to use the feature of customized steering wheel images (why is there a feature like this, when you basically can’t use it without hitting the CPU like that?!)
I find it strange to just come to the conclusion that’s a non-issue.
You can decide not to work on it, but it certainly is an issue.
I appreciate a lot that you are that reponsive and take a look at everything MIka, but I also get the impression that with many problems they seem to be ignored or there is an excuse of why it is not an issue and remains. The same thing happened with Simucube not working with City Car Driving. Other FF products and drivers work fine with this simulation, but Simucube does not. Ok, the CCD devs are not the most interactive and helpfull out there, I got that - but point is, that other products work fine and Simucube does not. There is a reason for that, but it does not get taken care of. A bit dissapointing as far as supporting a high-end product goes.
I think the 3% CPU usage is not an issue if it does not happen while you play a game i.e., when the game window is on top of everything.
While you are changing settings etc. in TD, then an extra 3% on one screen which you don’t even interact with a lot, is also a non issue.
Task manager shows the following:
TD on top, showing the initial page with the wheel 1.5%
some other window on top (like a browser), turning the wheel 0.5%
some other window on top (like a browser), not turning the wheel 0.3%
some other tab in TD turning the wheel 0.3%
0.3% doesn’t seem to be that much, but if your idle CPU is more than that you might have a lot lesser CPU than I have and then you need all those extra cycles to play the game for sure.
I think fixing that outside of the used framework is getting close to diminishing returns. Some other more easily achievable optimization would have a lot more drastic result.
If you want to see a picture of the wheel which is in front of you that means you have to use a protocol/software to look for it, loading it and making sure is there for the time you wanna have it there. Even when you have a lot of games (I have 18 racing games) and Fe 3 wheels doesn’t make it necessary to have truedrive in full windows all the time. Changing wheel, changing game take quite some time. Therefore is no need to have this active all time. This is no MotoGP flag to flag race where profile swap time is a matter of winning or loosing. I have a formula wheel with Nextion display and have to run Simhub. I was aware that this would use ram and CPU. I have a PC only for simdriving. I use software to shut down stuff not needed and change priority in task manager. An I9 using this amount compared to my I7 (which uses 0.4 when windows open and 0 when minimised but is powered usb) either the difference is in the graphical demand or an issue not yet discovered
This discussion is of course important, but one of the reasons we are not working on it, is the fact that we intend to rewrite True Drive anyway quite soon, so benefits of spending time on it now are soon diminished. The main goal of the rewrite is to add support for our upcoming new products (now True Drive is pretty much built for just one device and device type) and also to get a more modern looking user experience.
I see, that makes perfect sense IF the timeline for those projects is backing it up. I am currently aware of two other projects giving the very same explenation of why issues are not being fixed - ongoing over many months and years by now. (Media Monkey music organisation software and Teamspeak…)
Also it sounds like it might become even larger and more complicated which normally does not help with bugs, issues and performance. But well, I hope for the best! Anyway having started this discussion with a complaint, I do want to point out that I am very happy with the way things work since the permanent high torque feature got implemented.
