problem hiding not existing cores per CPU measure

[Yue]

SilverAzide » May 9th, 2023, 6:23 pm
I use Lua to configure the skin because the logic is more complicated than what you can do with Rainmeter. Lua is definitely not needed if you just want a simple/normal skin that shows 64 or fewer logical cores.
[...]
P.S.: The ActiveNet doc is Gadgets\@Resources\ActiveNet_Readme.txt.

Thanks again for the hint. I read, I tried and it helped with some additional information - the amount of cpu curcuits and the amount of physical cores (what I would have asked about later but that is already answered now by your plugin).
But as you wrote, "lua not needed" to show "logical" cores. I thought with your plugin it was possible to show the physical cores´usage (like the average of the corresponding two logical processors if there are two), which is what I asked before. As I understand now, even while your skin names them "Core1", "Core2" (...) these too are logical ones and (regarding cpu, not network and the other options it provides) your plugin is (only) used for the tooltip information on physical amounts of cpu and cores, right?
Then I cannot imagine a way to get the usage of the physical cores (no matter whether they have one or two logical processors).

[SilverAzide]

As I understand now, even while your skin names them "Core1", "Core2" (...) these too are logical ones and (regarding cpu, not network and the other options it provides) your plugin is (only) used for the tooltip information on physical amounts of cpu and cores, right?
Then I cannot imagine a way to get the usage of the physical cores (no matter whether they have one or two logical processors).

Yes, you are correct, these refer to logical cores only. Windows does not "see" physical cores when it reports usage stats, it only sees logical cores. There is no way you can get usage of physical cores since Windows does not use these directly.

The ActiveNet plugin is not used only for the tooltip, it's used to configure the skin as well. The skin (due to the plugin) is NUMA-aware and SMP-aware, and configures itself accordingly. It also figures out how each logical core maps to each physical core, which is used to map temperature sensors to logical cores.

[Yincognito]

Then I cannot imagine a way to get the usage of the physical cores (no matter whether they have one or two logical processors).

In addition to what SilverAzide mentioned, if you check here and here, you'll find out that this can be either simplified / averaged to logical cores / processors, or the solutions, if they exist, are a bit difficult to implement, at least by using just native Rainmeter code. Sure, the questions are for C#, but if that has so few answers, if any, you can imagine how many solutions exist for, say, command line or other tools. HWInfo64 has some data on pysical cores, but it's either about voltages or roughly the same performance calculation for frequencies as for logical cores but depending on a not so set in stone "core order":

Physical Cores.jpg

So, it looks like sticking with logical cores is the best idea...

[Yincognito]

2. example: corresponding to the Memory bar
2.1 first solution:
-"RAM Memory", "Disk Pagefiles", "Total Memory" - title color as "CPU" on the bar, because they are titles.
-the same goes for "Kingston Kf..." and "C:\pagefile.sys"
-the value and the value sign [in this case MB and behind that the percentage with its sign] for the RAM memory in blue [= bar], for Total Memory in green [= bar] for Disk Pagefiles in orange [= bar]
-the same way for the RAM Memory and Pagefile values and signs under the ● ● ● -dividers
If that is not an option, whatever the reason, why not creating a new style and in order not to make it too colorful, using a light grey for "OtherStats"?

There were two suggestions in my last post (described in the second example): I would use something that´s not as eyecatching as the title color and while you don´t want to get too colorful (expecially since you stated you don´t want to have a resemblance with SilverAzide´s Gadgets) I would use a color that´s going soft on the eyes (yeah, no red^^) like grey. A more neutral color (or at least as you already mentioned not more than another color) would divide the output - at the top the shortened details from the menu bar in full length in the tooptip, easy to recognize by using the same colors, on the other hand additional information at the bottom, easy to recognize be the fourth color not being so intrusive. I know your intention is to seperate different parts of contents there to ease the visual access. But too many color changes could have the opposite effect because of eyes then concentrating on these changes instead of what they resemble.

Well, I did apply your suggestion to a tooltip skin that's typical when it comes to the diversity of the layouts, orders, texts I can have in a tooltip, and this is the result (left = old style, right = new style) - you tell me if it'd work or not (the colors are not important, as they can be changed, I'm talking about the way they're distributed):

Tootltip Style Comparison.jpg

The thing is that I can have literally everything in tooltips, and that is the whole point, because that's why they're superior to the standard ones (albeit slightly more complex to implement, which is why I made a "tutorial" at the time in the Tips & Tricks section of the forum). That means I can have a large number of things not present in the main skin, I can have them in a different order compared to the main skin, I can have lines without the ● dividers or separated in two by them, I can have a basicly formatted list or a more thoroughly formatted layout below the ● ● ● dividers or even switch between upside and downside styles according to the content that needs to be displayed (see the Audio vs Player layouts), and so on.

The coloring therefore needs to be adaptable to all cases (yeah, I'm one of those one size fits all folks especially if I want to avoid endless personalization from case to case), and while I can no problem adjust the 3 or 4 regexes to color stuff properly in one case, other cases might involve customizing them differently for those cases. In effect, I'd end up partially doing what I wanted to avoid from the start (bothering with tooltips on a per skin basis) - for example, the disk usage percent value above is integrated into a complete line, within round brackets, but in another skin it might be the way rates are or in any other way it is fit for the rest of the content (it could even be another value altogether within brackets). Since regex is based on the (diverse) existing content and the (fixed) configured patterns, it would require per tooltip adjustments.

In a way, main skins have a fixed layout (i.e. small column | large column | small column | large column, that suits every data I put into them, if not, I merge some and / or I scroll text), while tooltips have a free layout (i.e. diverse data, layouts, order, that again suits everything I put into them). I'd like to keep this "I just plug data in and it automatically works" system in both, because it makes it so easy to add or modify any of them.

P.S. Of course, in the Processor / CPU skin earlier, the coloring on the right would be perfect... but as you can see, this is not always the case.

[Yincognito]

Quick question... I'm about to start adding the line showing the average usage over a period of time to some of the skins in my suite. Almost all of the skins, bar the Processor / CPU one, use scrolling to allow the user to navigate through different instances of what is displayed in them, e.g. various GPUs, drives, networks, and so on. This has the advantage of requiring way less code (since only the currently scrolled instance is measured and displayed), probably less CPU usage for the skin, less space needed for the details in its tooltip, and more clarity when displaying them since it's just one instance at a time. The disadvantages of the other variant are the opposite of the above, but now with the line about the average in mind, there could be one disadvantage of scrolling in this case, mainly about starting to "record" data on average and period only at scroll time and not necessarily at skin load / refresh time.

So, what about making the Processor / CPU skin also scrollable over the overall CPU and its cores? This way, each core would be displayed separately on scroll, the core data would need less space in the tooltip, and the average could even be measured by core. The disadvantage is that the measurements would start at scroll time and the entirety of core data will probably not be displayed. I initially didn't make the Processor skin scrollable with the idea of one day scrolling over multiple physical processors, as opposed to cores of the same physical processor, but is that even likely to happen (and even if it does, I could use the middle button to scroll over actual processors, if needed)? What do you think?

[Yue]

Yincognito » Today, 9:54 am
Quick question...
So, what about making the Processor / CPU skin also scrollable over the overall CPU and its cores? This way, each core would be displayed separately on scroll, the core data would need less space in the tooltip, and the average could even be measured by core.

Not sure about the naming here...do you mean switching between views of (1) physical core(s) usage(s) and (2) all logical processors or one (scrolled) view for each logical processor (because I cannot imagine you really mean that one)?

While the problem is the average and its monitoring (the restart on scroll):
Is there no way to make an exception in your code just for your CPU skin (maybe marked by a variable in-between) no matter which view is active to keep the monitoring of the average running (resulting in not deactivating the average measurement since I guess that´s what you are doing to attempt less CPU usage for the skin)?
Another approach I can think of quickly would be this: Why not making the average a static element which is (visually imperceptable) added to the top or bottom of the tooltip ([Tooltip.part2])? Technically the tooltip would be split, visually still be one.

I initially didn't make the Processor skin scrollable with the idea of one day scrolling over multiple physical processors, as opposed to cores of the same physical processor, but is that even likely to happen (...)? What do you think?

I don´t feel adressed by this question and I guess it wasn´t meant this way.
SilverAzide or some system (not forum-) administrators might know more about how these values are determined by Windows or jsmorley whether this could be measured by Rainmeter in the future.
I (only) could tell you, how I am approaching this, of course, since I had nearly the same idea, preparing for this being possible one day eventually and then not having to rebuild my whole skin code.

[Yincognito]

do you mean switching between views of (1) physical core(s) usage(s) and (2) all logical processors or one (scrolled) view for each logical processor (because I cannot imagine you really mean that one)?

Is there no way to make an exception in your code just for your CPU skin

I don´t feel adressed by this question and I guess it wasn´t meant this way.

Yeah, I know, naming is a bit confusing / overlapping in these cases. But let's put it another way, hopefully crystal clear - in the realm of processing units this is the structure that all computers have: 1 or more physical processors - (that each can have) -> 1 or more physical cores - (that each can have) -> 1 or more logical cores (Windows Task Manager calls the latter logical processors, but that's just semantics, really - like you said, the key in differentiating is physical vs logical, or physical vs virtual, if you like).

Originally, my skin was designed so that at some point in the future it will be able to navigate via scrolling through multiple physical (and separate, of course) processors. However, since probably all regular users have just 1 physical processor (divided into physical cores, themselves divided into logical cores or logical processors as Task Manager calls them) and multiple physical processors are used almost exclusively in supercomputers, I thought that I should forget about scrolling through multiple physical processors (which we regular users won't buy in our lifetime anyway) and just scroll through the single physical processor and its logical cores instead.

In other words, if I would scroll through logical cores, I wouldn't display the whole list of logical core frequencies, usages and temperatures when I'm on the single / overall physical processor that we all have, but I would instead display each logical core data in its own "navigation page", if you will, according to the scrolling. For example...
- no scroll: tooltip made of logical core count, frequency, usage, temperature for the single (or overall) physical processor
- scroll once: tooltip made of current logical core number aka 1, frequency, usage, temperature for the logical core number 1
- scroll twice: tooltip made of current logical core number aka 2, frequency, usage, temperature for the logical core number 2
... and so on ...

The disadvantages, as I said, are not viewing all core data on the same page anymore, and the counter for the average and period over which the average is measured not starting until the said logical core is scrolled over. The advantages are multiple and significant, at least in terms of development and efficiency, so I'd prefer it, as the skin designer. My question was what would you prefer, as a hypothetical user? Do you think this (scrolling over logical cores this way) would be acceptable / illustrative / match expectations or user needs?

Note: In terms of code, it's not about deactivating anything. It's whether I should have 33 measures for physical processor + logical core nominal frequencies, 33 for their usages, 33 for their temperatures, 33 for their percent of nominal frequencies, 33 for their actual frequencies based on the percent and nominal frequency product, plus another 2 or 3 for computing the average and period for only the physical processor in order to avoid multiplicating them again by 33, running at all times (32 is the maximum number of logical cores I am willing to display) ... or just 1 measure of each, plus the same 2 or 3 for the average part, but for the currently "active" or "scrolled" physical processor / core (avoiding multiplicating is not needed here, but they will obviously "switch" to the said physical processor / core only on scroll).

P.S. If I scrolled through physical processors, making an exception wouldn't be needed since I would only do the average part for the physical processor, and not logical cores (adding another bunch of measures to the already many of them or the inabilty to display yet another long list of values are good reasons for that). If I scrolled through the one physical processor and its logical cores, making an exception would mean that instead of the 2 or 3 measures I mentioned above, I would need to have ((2 or 3) * 33) to monitor logical cores at all times as well. Not overkill, but the, who doesn't like a skin made of just a couple of measures?

[Yue]

Yincognito » Yesterday, 4:29 pm
Well, I did apply your suggestion to a tooltip skin that's typical when it comes to the diversity of the layouts, orders, texts I can have in a tooltip, and this is the result (left = old style, right = new style) - you tell me if it'd work or not (the colors are not important, as they can be changed, I'm talking about the way they're distributed):

I am not sure what you mean by "distributed" if it is not about colors, since we only wrote about them - the layout? But that is totally up to you, you are the author and it´s your skin...

you tell me if it'd work or not?
P.S. Of course, in the Processor / CPU skin earlier, the coloring on the right would be perfect... but as you can see, this is not always the case.

And since there is no layout without thinking of colors: It won´t work that way, but that´s on my account. Now that I see it I recognize a mistake in my suggestion. white and grey should be switched around, because the eyecatcher should be the value not the naming. Looking at your skin again and again users will automatically focus on values, especially because at some point they will know, what´s shown where, and that should be helped with.
For better visualization I messed with your screenshots...(the grey is a bit too dark)
side note: On the disk total I put the percentage at the start instead of the end. It is more important for quick information (for details users keep on reading that line) and this way the word "used" isn´t necessary any longer.

The coloring therefore needs to be adaptable to all cases (yeah, I'm one of those one size fits all folks especially if I want to avoid endless personalization from case to case), and while I can no problem adjust the 3 or 4 regexes to color stuff properly in one case, other cases might involve customizing them differently for those cases. In effect, I'd end up partially doing what I wanted to avoid from the start (bothering with tooltips on a per skin basis)

If you want it colored differently, I don´t know any other way. The only option would be to use only a few colors but more unified like for title, category, (every) value(+sign if there is one), other stuff (beneath the dividing dots). This way you could keep the code as short and simple and it would fit your likings of "I'd like to keep this "I just plug data in and it automatically works" system in both, because it makes it so easy to add or modify any of them".

[Yue]

Yincognito » 5 minutes ago

You are answering just to quick. I had hard times answering the other one right this evening (still haven´t eaten a bit today). The reply on the last post I have to do later (unfortunately), but will come soon.

[Yincognito]

You are answering just to quick. I had hard times answering the other one...

I think the length of my replies is the problem - I tend to make my posts longer than optimal in order to cover everything I want to transmit.

So, I'll keep it shorter this time, to make it easier: I don't think your suggestion about colors in the current form is the best idea for the tooltips of my skins, which is a real pity because otherwise similar coloring to the main skin makes perfect sense. I guess a blue, green, orange base along with some randomized but different coloring for the rest of the values would probably be ideal, and I will think about that, so the idea is not lost, I just need to find a way to implement it properly, without potential drawbacks in other areas of the code.

The main obstacle here is, like explained in the other thread, the fact that regex doesn't care about the meaning of the pattern (e.g. I can't say "look for the value of this or that"), it only cares about the characters that enclose it (e.g. I can say "look for the value enclosed by those chars"). Since the latter are so diverse because the data and its logic are also diverse in the tooltips, that would mean I'd have to use different patterns for tooltips of different skins, something I wanted to avoid all along (one tooltip with a very generalized and abstract structure is best in this case).

That being said, I'm quite interested in a hypothetical user perspectve regarding the scrolling / averaging in the Processor skin I mentioned earlier. Not necessarily how you would do it, but you'd like it to be if you were an user of such a skin. A "what if" scenario, if you like.