Nice!

I think there are too many changes in one patch. I personally agree with some of the changes but not all.

+1 for the context menu to disable certain info, but not all of them. Is this stored in the .blend file like other editor features? I'd say no, what if I save without notifications and send it over to someone? They'd miss on errors.

Also, notifications showing on the far right are easy to miss, move the whole text to the side. I agree centered is not perfect either, but I would rather have them take the *whole* status bar for a moment. Nobody is reading the errors report and the stats and the shortcuts help at the same time. Let's just focus on one type of information

My suggestion:

• Don't make notifications an option.
• Take over the whole status bar for a (little longer) moment.
• There will be even room for a "Read more" button to open the info editor, which now happens on click over the text and it's rather obscure.

I like this! And all the options!

It does look pretty empty down in the bottom right corner by default though.
If the goal is to make room for the notifications on the right (which I think would be great), couldn't the notification just replace these stats when it appears?

@Hans Goudey (HooglyBoogly) - It does look pretty empty down in the bottom right corner by default though.

Yes, this is just how the current plan is. If it were up to me it would show something by default as that would lead the user towards further customization. Otherwise it is pretty hidden. You might think of right-clicking on something, but most people wouldn't think of doing so on nothing.

Another concern is that these are stored with the SCREEN. So the same as whether the statusbar is shown at all. But that means these things stick with the blend so you'd need to update default startup blend. Not sure there are other ways of doing it Wouldn't want these to be user prefs that are not set inside Preferences as that leaves them disconnected from saving prefs.

In D7557#195549, @Harley Acheson (harley) wrote:

With this version scene statistics can be optionally shown in statusbar, which appears to be the current desire of the IT team.

Will likely need more testing.

Well, now we can use onscreen stats display in case of lowpoly/gamedev charater/asset modeling - for realtime control, and use status bar stats display in cases of heavily loaded viewport, during architectural, CAD or photoscans mesh cleanup work,
to make model and stats display independent from each other in that cases.
That is proper design of this feature, thank you!

That's the problem of industry standards design solutions, like onscreen stats display from max/maya - their issues are well known for decades, so just putting them in Blender it is not the best way to innovate Blender.
All of them should be properly rethought and revised before implementation, at least because they were invented in the 90s, when CG was not that complex as today.

In D7557#195773, @Julian Eisel (Severin) wrote:

Design Question: At what level should the scene stat settings be stored? Right now it's stored per screen-layout essentially. It could also go to the Preferences.

Even if we decide to keep it at screen level (like in the current version), the implementation should be tweaked, so requesting changes.

A very nice question.
In my opinion the way stats are displayed is workflow dependent, so Architectural/Scene design modellers (cluttered viewport - statusbar stats) and Character/Asset/Gamedev modellers (uncluttered viewport - overlay stats) will prefer to see stats constantly at single place they selected.
I mean, the way stats are displayed is not an option that will be switched frequently during work in my opinion.
So I think it can be stored at Blender prefs level (not per file or layout), at least for statusbar stats, since statusbar does not depend on the workspace layout by design.
Wide-range artists like generalists may require more freedom, provided by workspace layout overlay stats storage, so overlay stats should be kept per workspace layout - as a regular overlay.
But, of course, such an assumption requires tests and verification.

I know its the design and not your patch, but I really don't think this area should be empty by default.
"Right click on the blank space to get the status bar text back" is just about the least discoverable feature I've seen.
So I think the design should be revisited here, especially because everyone I've heard talk about it has agreed with that.

Other than that, I really like the customization you've added here! Just two things I would change:
1
I don't see the need to have both VRAM load and GPU memory usage. Especially because the numbers are pretty small, the "load" is redundant. Knowing that 1.33 GB is 19% of 8 GB doesn't really help me use Blender.

2
I don't like this: #ifdef WIN32. If it's included in Blender it should work on all operating systems we support.
It doesn't feel particularly important for Blender to take on the role of a system monitor type thing, but if it's important enough, I managed to get something working (P1501) on Linux, but it includes cache memory too.
(See https://stackoverflow.com/questions/63166/how-to-determine-cpu-and-memory-consumption-from-inside-a-process)
It probably makes more sense to read some /proc/ file, but I didn't find something that would give global memory without cache. I'm sure it exists though.

I don't have a strong opinion on where these settings should be stored, only that if they're stored in the preferences I think we should keep the
right click menu as a quick way to access them.

In D7557#198745, @Hans Goudey (HooglyBoogly) wrote:

I know its the design and not your patch, but I really don't think this area should be empty by default.
"Right click on the blank space to get the status bar text back" is just about the least discoverable feature I've seen.
So I think the design should be revisited here, especially because everyone I've head talk about it has agreed with that.

Yes, otherwise new users will not know that such a thing even exists.
Also the reasons of keeping empty space instead of useful information are not clear.

1
I don't see the need to have both VRAM load and GPU memory usage. Especially because the numbers are pretty small, the "load" is redundant. Knowing that 1.33 GB is 19% of 8 GB doesn't really help me use Blender.

We are working on different hardware in our company, so percentage is confusing in our case - we can't say if scene, already opened on some computer, can be even loaded on a free computer without fuguring out hardware specs and calculations.

I don't have a strong opinion on where these settings should be stored, only that if they're stored in the preferences I think we should keep the
right click menu as a quick way to access them.

Yes, right click is a nice way to access statusbar prefs, even if they are stored per application (not per blend or per workspace)

@Hans Goudey (HooglyBoogly) - know its the design and not your patch, but I really don't think this area should be empty by default. "Right click on the blank space to get the status bar text back" is just about the least discoverable feature I've seen. So I think the design should be revisited here, especially because everyone I've head talk about it has agreed with that.

I agree 100% and have always thought so. I see some debate on whether it should should show all the old info by default or just some subset, but blank does not work.

I don't see the need to have both VRAM load and GPU memory usage. Especially because the numbers are pretty small, the "load" is redundant. Knowing that 1.33 GB is 19% of 8 GB doesn't really help me use Blender.

It is not intended that these both would ever be selected, but that a user would select one or the other.

Knowing that 1.33 GB is 19% of 8 GB doesn't really help me use Blender.

It isn't though, which illustrates part of the problem. Many video cards give just amount free. In that case it is pretty clear when shown as "Free VRAM: 1.33 GiB". Other cards give both free and total, but that means that showing "GPU: 1.8 GiB / 8 GiB" is showing you that you have used up most of your VRAM, not little. The "VRAM Load" is an attempt to show this in an intuitive manner, in this case would be 83%. And no, I don't intuitively see that I have used 83% of my VRAM when seeing " 1.8 / 8". I'd be happy to get rid of the "Load" option if I could show the usual display as "GPU: used / total", rather than current free / total, but I lost that argument. LOL

I don't like this: #ifdef WIN32. If it's included in Blender it should work on all operating systems we support.

For platform-varying things, I don't think we should make a rule where nothing can be done unless simultaneously done for all. I'd rather start with one, add a todo and let other platform devs fill in what is needed when they can. Otherwise we are waiting for some mythical dev that can work on all platforms at once.

It doesn't feel particularly important for Blender to take on the role of a system monitor type thing

No, but it is handy, while the (usual) amount committed by Blender isn't really useful in most cases. And when it is, at the extremes of usage, a system-wide value is far better. But, as with the VRAM options, this is just an added option, so users could select whatever they want rather than have us decide for them.

I don't have a strong opinion on where these settings should be stored, only that if they're stored in the preferences I think we should keep the right click menu as a quick way to access them.

I really don't know how to deal with where these are stored. If in preferences then that is global, affecting all windows. That is fine, but it would be nice to support multiple main windows. And also no sure about when Preferences are saved when doing so outside of the preferences editor.

@Paul Kotelevets (1D_Inc) - We are working on different hardware in our company, so percentage is confusing in our case

in that case I would suspect that you would not select load but show the values instead. That is why I give two separate options there, so you can select what you want. Note that you only get a choice of two options if you video card supplies both free and total. Otherwise you only get one choice that shows amount free.

When your card gives amount free and total, then you can choose either of two options: free amount / total amount or percentage used. So if you have used most of your VRAM the two choices might show either of these at the same instant: "GPU: 1.8 GiB / 8 GiB" or "VRAM Load: 83%"

This "load" option is my attempt to address my own confusion on the use of free / total instead of used / total.

In D7557#198764, @Harley Acheson (harley) wrote:

This "load" option is my attempt to address my own confusion on the use of free / total instead of used / total.

What kind of confusion?

@Paul Kotelevets (1D_Inc) - What kind of confusion?

I thought I spelled it out in that same paragraph. Some video cards only give "free" while others give us both "free" and "total". But when given both I do not like displaying the state as "free / total". I find it more logical to show it as "used / total" instead.

So in the example of having a video card that has 8 GB VRAM and you have used the majority of it, 6 GB. For many video cards the best we can display is "Free VRAM 2GB". For others we have the total as well and can show "VRAM 2GB / 8GB". But I find that backwards and would prefer to show it as "VRAM 6 GB / 8 GB" instead, but don't have anyone agreeing with me on showing it that way.

So having this other option gives me what I want to see: it would show it as "75%", which shows the percentage USED, not the amount FREE.

In D7557#200483, @Harley Acheson (harley) wrote:

@Paul Kotelevets (1D_Inc) - What kind of confusion?

I thought I spelled it out in that same paragraph.

Sorry, my english is not good sometimes.

Some video cards only give "free" while others give us both "free" and "total". But when given both I do not like displaying the state as "free / total". I find it more logical to show it as "used / total" instead.

For sure. Easily understandable.

So in the example of having a video card that has 8 GB VRAM and you have used the majority of it, 6 GB. For many video cards the best we can display is "Free VRAM 2GB". For others we have the total as well and can show "VRAM 2GB / 8GB". But I find that backwards and would prefer to show it as "VRAM 6 GB / 8 GB" instead, but don't have anyone agreeing with me on showing it that way.

Thats super strange, because it clearly shows how much vram your scene takes. It is primary scene parameter.
Is it because of cards that provide only free value, to not to confuse it with used/total when it is available?
So, for cards that provide only free value there will be just single option available to display - free vram in GB?

So having this other option gives me what I want to see: it would show it as "75%", which shows the percentage USED, not the amount FREE.

How this percentage is obtained - is it provided by card?
Or it is calculated only for cards that provide free+total values?

@Paul Kotelevets (1D_Inc) - Thats super strange, because it clearly shows how much vram your scene takes.

Yes, I would prefer to show how much the scene is TAKING rather than what is LEFT to be taken. But I have yet to convince anyone else that this is backwards. If I have a jar that can contain 100 coins and I have filled it with 80, the status I prefer to show is "80 / 100", so how much it is full. Showing "20 / 100" just seems odd to me.

So, for cards that provide only free value there will be just single option available to display - free vram in GB?

Yes, video cards either give free or both free and total, none give just used. A card that only gives "free" will show "Free VRAM: 2GB"

How this percentage is obtained - is it provided by card? Or it is calculated only for cards that provide free+total values?

Yes, only for cards that provide both free and total, I just subtract one from the other to get used and divide that by the total.

>>! In D7557#200485, @Harley Acheson (harley) wrote:

But I have yet to convince anyone else that this is backwards.

The only issue I see here is "political" one - it may be hard to explain to users that issue with cards that provide different data, to answer possible endless questions like "why my neighbour can see used vram, while I can see only free".
This way it is a consistency that is built from a limitation.
But from any other point the ability to see used vram when it is possible is highly appreciated.

How long is the list of cards that provide only free value?

Great! Haven't tested the patch but based on the screenshot I've got some notes about the labels:

• Rename the title Status Bar Options to Status Bar, they are all options anyway.

• Use Show as title of the row, then remove Show from all the items (like in the Viewport Display panel for objects). This should be done only in the UI code, not in the RNA so when searched or in custom menus it'd be named properly.
  
• Rename Show Memory to System Memory
• Rename Show VRAM to Video Memory (Video Ram or VRAM can be mentioned in the tooltip)
• Rename Show Version to Blender Version

Just thinking of the possibility of sharing settings between computers that do and don't support it.

What actually this setting does?
We are currently discussing teamwork issues caused by extensive flexibility.

https://developer.blender.org/T75672#976377

In D7557#201116, @Harley Acheson (harley) wrote:

I'm not sure what you mean with this. This include should go where?

Right down below with the other GPU* includes, in the #ifdef RNA_RUNTIME section.

Also not sure on this. What I did is make that option be disabled if not applicable. Is there some other way to do this so it is not visible instead, or something else? Is there an example elsewhere you can point me to?

I just meant something like sub = col.column().. col.active = GPU_..
But that would necessitate exposing that GPU check to Python. It's not a big deal at all anyway, just something I thought of.

Am I right to assume that the "Blender Light Theme" crashes blender due to these changes?

Are you guys aware that having a monospace font makes the status bar almost impossible to read since it gets cut off? Unless you MMB drag you won't see most of it.

@Roel Koster (kostex) - Am I right to assume that the "Blender Light Theme" crashes blender due to these changes?

Is there something in particular that makes you think that? If I change my source to before my commits I get the same error. And there are a whole bunch of commits prior to that by Clément having to do with things close to where that crash happens when changing to "Blender Light"

In D7557#202932, @Harley Acheson (harley) wrote:

@Roel Koster (kostex) - Am I right to assume that the "Blender Light Theme" crashes blender due to these changes?

Is there something in particular that makes you think that? If I change my source to before my commits I get the same error. And there are a whole bunch of commits prior to that by Clément having to do with things close to where that crash happens when changing to "Blender Light"

It was just an assumption.. and a wrong one I'm afraid.. sorry for that.