Page MenuHome

UI: Status Bar Changes
Needs ReviewPublic

Authored by Harley Acheson (harley) on Apr 28 2020, 6:20 PM.

Details

Summary

This is the 2nd step of the design described here: T75672

Now that scene statistics are an (optional) overlay in the 3D View, what is left is a bit of an odd orphan. This is an attempt to clean that up.

What is left to show in the Status Bar is not related to the scene, shouldn't be a function in the Info Editor space, shouldn't store a string in the view layer, etc. So the majority of this patch is digging that stuff out of there.

We already have a Screen option to show the Status Bar or not (Window / Show Status Bar). So I have added some sub-options to allow the enabling/disabling of different parts of the Status Bar.

Although this adds more options, my thought is that these would not be easily exposed in a menu or in Preferences. You would remain with one large switch to turn it all off and on with "Window / Show Status Bar". For finer control of what is shown you would right-click on the status bar itself and select what you want to see from a popup menu.

Less visible is that this also changes the order and placement of the parts in the Status Bar. Currently it is showing everything in three sections. Some things left-aligned, some things in the middle, then some that are at the right:

Input statusNotifications, Progress BarInfo

This patch changes that so there are only two sections, stuff on the left and stuff on the right and nothing in the center:

Input statusInfo, Notifications, Progress Bar

Yes, this means that when you receive a notification, like "Deleted 1 Object" it will appear at the extreme right and push the other info over. I love this part. Not only are the Notifications in a consistent place, but that "pushing over" is about the right amount of noticeable for me. Your mileage may vary. LOL.

Diff Detail

Repository
rB Blender

Event Timeline

Harley Acheson (harley) requested review of this revision.Apr 28 2020, 6:20 PM
Harley Acheson (harley) created this revision.

Not really my area, but I don't think exposing memory in percentage is the right thing to do.

For example, in the studio it is a common task for artists to optimize scene for a specific memory size so that render nodes with less amount of memory can still render the shot. Exposing value in percentage will make it so artists need to do more mental math to keep track of how close they are to their goal.

Another example is that for regular artists it is also confusing. Different computers will have different amount of memory, so the same scene will show different percentage. What is even more confusing, Blender might crash on 70% reported memory just because the rest 30% are used by video player and web browser.

Another technical example is that it is useful to know whether Blender pushed system to swap or not. With percentage based display it is harder to know.

I agree with @Sergey Sharybin (sergey). We should not show the percentage alone. The design tests we did that showed a bar also showed the actual amount used.

In general I think these changes are somewhat a waste, which will become moot, because the idea is that all this information about memory used should be disabled by default, as per the design doc: https://developer.blender.org/T75672.

IMO it's not worth it to make nicer ways to display the amount of memory used, when users will just use the OS-supplied system monitor instead.

This also keeps the pipe symbols, making the spacing between items very hard to see. Should be like this instead:

It has the wrong defaults (RAM and VRAM should be hidden by default), so we can use this space for nicer notifications and progress bars:

And, a more elegant way to show/hide items, could be to right-click on the Status Bar itself, as mentioned in the design doc above:

@Sergey Sharybin (sergey) - I don't think exposing memory in percentage is the right thing to do

Thanks! This is (so far) just playing around to see what is available and what works.

@William Reynish (billreynish) - I agree with @Sergey Sharybin (sergey). We should not show the percentage alone. The design tests we did that showed a bar also showed the actual amount used.

Actually that does not represent a common opinion between you. Your "RAM" display shows ONE number and implies a percentage of total. Sergey also wants to see swap amount when that occurs. That would require the current display of showing both memory allocated (not system-wide) and swap amount.

In general I think these changes are somewhat a waste...

Never as waste as I enjoy experimenting, hence the "Experiment" in the title.

should be disabled by default, as per the design doc: https://developer.blender.org/T75672.

What is enabled/or disabled by default is not part of this because I don't want to have to enable it all to see it while experimenting. But I don't think you could manage to have "version" off by default.

This also keeps the pipe symbols, making the spacing between items very hard to see...

Maybe. Using spaces might work, depending on the what is shown at the end.

Your design doc does not show a RAM display that actually works. If using memory allocated by this instance of Blender, rather than memory used globally, there is no relationship to "total" really. Similarly your display of VRAM assumes we know both total and used, but that is only the case with Nvidia, For many other cards we only get used. This might mean we are stuck with just text and cannot get to what you show.

And, a more elegant way to show/hide items, could be to right-click on the Status Bar itself...

That detail was specifically mentioned in the original comment above.

While it would be useful to show available memory, I'm not sure you can actually get meaningful values for that from the OS or GPU. Both will keep a bunch of things in memory for performance, that they are then able to free if more memory is needed. Personally I would not try implementing that kind of statistic at all, it will be misleading.

@Brecht Van Lommel (brecht) - While it would be useful to show available memory, I'm not sure you can actually get meaningful values for that from the OS or GPU...

For sure. These were mostly me thinking "hey, if we want to have options for what is shown, why not have more", but then lacking good imagination. LOL.

The "memory load" is an awesome metric supplied by Windows, but doesn't really work when combined with other similar numbers down there. Especially since we only get free vram for many video cards and not a total. So we end up with a funny combination of showing used ram but only free vram.

Locally I am back to showing stats largely as they do currently (but playing with spaces instead of that damn pipe. And trying to get a bloody context menu working down there, but that is not cooperating so far. LOL

Updated to include (non-working) code trying to get a context menu in the keymap editor.

Update to current state of master. Now have a context menu for these options that does work when called elsewhere, but I still cannot figure out how to call from a status bar keymap item. Frustrating...

Harley Acheson (harley) edited the summary of this revision. (Show Details)May 10 2020, 9:46 PM

Can now right-click status bar to select what to show.

Harley Acheson (harley) edited the summary of this revision. (Show Details)May 11 2020, 2:58 AM

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.

Now can only control memory, vram, and version, and ALL are off by default. Should compile on Mac now.

Harley Acheson (harley) edited the summary of this revision. (Show Details)May 12 2020, 9:24 PM

Excellent. This works well now.

This gives a more fixed space for rich notifications:

And it allows to optionally add other things for those marginal use-cases where one might want to see that information:

This revision is now accepted and ready to land.May 12 2020, 10:09 PM
Harley Acheson (harley) retitled this revision from UI Experiment: Status Bar Changes to UI: Status Bar Changes.May 12 2020, 10:19 PM

Only show VRAM option on the context menu if it is supported by the current hardware

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.

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.

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.

Julian Eisel (Severin) requested changes to this revision.Thu, Jun 18, 4:26 PM

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.

source/blender/makesrna/intern/rna_screen.c
578–601

If these settings are kept at the screen level, they should be moved to SpaceStatusBar.

Global areas are currently not written to files currently, but that can be changed quite easily, at least for the status bar (see WITH_GLOBAL_AREA_WRITING). We don't even need to write ScrArea.global I think, currently that's entirely runtime data.

This revision now requires changes to proceed.Thu, Jun 18, 4:26 PM

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.

Updated to current state of master. And also...

Made some changes that bring it closer to my idea of having that section more "à la carte" and so being much more customizable. I've broken up "scene statistics" into two separate options. And there are different ways to display VRAM and RAM usage.

If using Windows you get the option of showing global memory load, so the same percentage of memory usage you see in Task Manager. Similarly if your video card provides both free and total vram (mostly just nVidia) then you get the option of displaying that as a percentage as well. Of course these are just new options, as you can still choose to show these things in the current fashion.

@Julian Eisel (Severin) - If these settings are kept at the screen level, they should be moved to SpaceStatusBar... Global areas are currently not written to files currently, but that can be changed quite easily, at least for the status bar (see WITH_GLOBAL_AREA_WRITING). We don't even need to write ScrArea.global I think, currently that's entirely runtime data.

I'm not certain what exactly you want moved and to where. You are probably asking for something very logical, but my own lack of understanding is letting me down here.

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.

source/blender/editors/screen/screen_ops.c
4255
/home/hans/Documents/Blender-Git/blender/source/blender/editors/screen/screen_ops.c:4224:6: warning: no previous prototype for ‘ED_screens_statusbar_menu_create’ [-Wmissing-prototypes]
 4224 | void ED_screens_statusbar_menu_create(bContext *C, uiLayout *layout, void *UNUSED(arg))
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4261

When we're adding new properties, lets try to keep the RNA UI names and these strings the same, we shouldn't have to manually set them here.

4263

Clang format (line is 101 characters)

source/blender/editors/space_info/info_stats.c
617
/home/hans/Documents/Blender-Git/blender/source/blender/editors/space_info/info_stats.c: In function ‘ED_info_statusbar_string’:
/home/hans/Documents/Blender-Git/blender/source/blender/editors/space_info/info_stats.c:630:13: warning: unused variable ‘gpu_used_mem’ [-Wunused-variable]
  630 |     int64_t gpu_used_mem = gpu_tot_mem - gpu_free_mem;
      |             ^~~~~~~~~~~~

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.

Updated to current state of master.

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?

Jose (Dogway) added a subscriber: Jose (Dogway).

@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.

@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.