Could be this task change to high priority? actually any workflow that implies subdivision is nearly dead.

@Sergey Sharybin (sergey) I have two CPUs, intel i7 4790 and amd ryzen 3700x, videos recorded in the Ryzen. I can also test it in other intel i7 and a old quad core.

In T70816#796065, @Philipp Oeser (lichtwerk) wrote:

Can confirm. (wonder why this hasnt been reported before...)
T58473 might be related.
@Sergey Sharybin (sergey), @Brecht Van Lommel (brecht): would you consider this a High priority?

Side effects of the actual subdivision.

I can confirm this bug, I wanted to report few days ago.

I think that it's not really necessary. The few users that ask for this is only because they don't have any way to work with nurbs surfaces and they are searching a way to avoid this limitation. From my perspective, although somewhat useful this, its real usefulness would be minimal compared to everything that would imply in the modeling. But taking into account that you can easily avoid the problem today.

I reported similar problem here

After try the test scene that user provide the problem is clear. In 2.79 when you render the same scene with OpenGL it is near to realtime But when you render with 2.80 and workbench, that must to be the replace to OpenGL render, it go really slow. Also the editor doesn't respond to user interact at same speed like 2.79 render.

One of the problems that I see in the brush system is that when you have hundreds of brushes, you must to fight with this textures in any context. Making the use of the texture field menu difficult in simple projects.

I don't see why don't use the face counts when Zremesher uses face count by default.

Like an artist I vote for face count, is the first thing that I do every time.

The problem is really clear if you try what I show you, see the bevel value in the STATUS BAR and compare with the value in the REDO PANEL, are not the same.

Let's see, if that's what I'm telling you, it doesn't apply the multiplier to the operation information.

how could not be a problem than a bevel of 32,7cm in the info bar give me a bevel of 0,32cm in the real scene? Both have to show 0,327cm, the correct value

In units

It have the units, meters by default, after the width, offset and depth modes.

In T70102#780575, @Jacques Lucke (JacquesLucke) wrote:

Please prepare the file a bit better next time, I don't quite understand why the file is in the image editor when I need to see the 3d view to see the bug.

In T70102#780448, @Jacques Lucke (JacquesLucke) wrote:

Please provide more information on how to reproduce the bug. I have no idea what I'm supposed to do in that file. Also make a screenshot that shows what's wrong.
Not sure if it is important for this bug, but there seem to be missing textures in this file. Please pack any textures into the file.

in adition to this, I want to propose make a optional "Auto 3d Cursor" mode that change the pivot point automatically to 3d cursor until the user change selection? For example, without the option activated, blender keeps the classic behavior. With the option enabled:

I will try to explain better.

Same happens with quick favorites

The bug is about that

Ok, the problem running blender appear to be "solved".

Other thing. I have deleted all my config of 2.81, the problem running blender doesn't happen in 30 tests. I put the config that I upload before, first time, first problem. SO I think that the problem is clearly my preferences/addons.

Drivers tested
430.64 - Same problem - I had this the last 5 months without problems until 2.81 with file browser
436.15 - Same problem - Newest drivers from nvidia website
431.86 - Same problem - Latest Studio driver
417.22 - Same problem - Oldest drivers that I can download from nvidia website

No, I understand. Could be a problem with drivers... but in that case it's a problem with drivers only with the 2.81 since the file browser branch was merged and that only happens with the filebrowser editor.

The part of the slow opening of blender happens also with 2.80

@Julian Eisel (Severin) I have created a video to show the problem of the change of the secondary window to the file browser, but instead of that I pick other bugs with the last windows 64 builds (I made 20 minutes ago)

The problem with freeze blender is happening to me with daily builds to open a simple image in a material or import a obj.

I can tell that i tried the branch days before an always found that problems when i tried to open the file browser. For that reason I was surprised when I see the branch merged

Here you have the file that show the problem every time

I go to see how to replicate the problem.

Also the perfomance when I move the windows of the filebrowser is really bad

Freeze the blender app 10-20 seconds

In D2897#128772, @Bastien Montagne (mont29) wrote:

Time to close this, afaik everything has been merged in master last year?

Will be a great addition to the actual system

In T68970#759409, @ThinkingPolygons (ThinkingPolygons) wrote:

LOL. Clicking on a bunch of vertices one by one at a high speed is dumb imo, I'd use circle select or something else. There are much faster selection methods for this.
As stated before, not a bug.

In T68970#759388, @Brecht Van Lommel (brecht) wrote:

Please leave reopening and triaging reports to developers. This is better as a discussion on devtalk, it's not a bug.

Let's see, it's not a down-side, it's a huge mistake.

I do not know, imagine that when you are programming all the pulsations have 200ms more lag and that if you write fast you lose 1 out of every 3 pulsations.

Is it a joke? Seriously.

In T65965#753228, @Harley Acheson (harley) wrote:

Just for completeness, my own (unpopular) opinion on this checkbox alignment issue is to treat checkboxes more like other items. Think of them like toggle buttons we already use all over. Or consider them like sliders with only two positions. The alignment issue goes away, they become all more consistent, and the hit area is much larger:

Maybe I'm wrong. But commenting

I want to remember this proposal in RCS with a lot of community support

I want to remember this problem that blender actually have if the user move the N-shelf to the left. The panel is place at right of T-shelf, making hard to use it.

I like the solution of a dinamic UI. I never supported it because I though taht could be a problem to implement.

In D4721#108386, @ronan ducluzeau (zeauro) wrote:

For users of Active Tools the pivot, snap, orientation,... are part of the configuration of the active tool.

For all users, these settings are fundamentals. They are not just used by active tools. They are used by all tools.

In D4721#108378, @Jean Da Costa (jeacom256) wrote:

This is getting confuse to me.
Anyway the only thing this patch does is moving the topbar to inside the viewport, nothing is really changed from a usage point of view, only that if there are multiple editors with multiple active tools, now each region have its own topbar and even if you hide it you still have access to the same settings in the N-panel isn't that?.

In D4721#108366, @Jean Da Costa (jeacom256) wrote:

Why would we hide the tools we need? this doesn't make sense.

I think my argument is clear. Why can't an active tools user see his tool options in the same bar as other users? Why don't we hide the tools that you and me need in the n-shelf and keep the header only for active tool users?

This patch only listens claims and needs of users of modal tools. The users of active tools are relegated, ignored and separated, in one way or another, from the rest of the tool options and users. It is not taking into account their point of view or their future user experience, because currently this user is almost non-existent.

In rB9573bf432c4b06d940b4b38cc455826f47518884#227192, @Campbell Barton (campbellbarton) wrote:

In rB9573bf432c4b06d940b4b38cc455826f47518884#226613, @Gavin Scott (Zoot) wrote:

In edit mode the upper-right corner kinda looks like a train wreck now:

All these different interaction points in different sizes and shapes, and that super-prominent "Options" menu which suggests it's going to contain every "option" for the 3dview. Combined with the loss of the "Overlays" and "Shading" words in the header means the true 3dview options are lost among everything else.

Multiple changes are planned here: D4721

In reality I only ask or support to invert the positions of editor type and object interaction mode. Interaction mode in the Tool Header and Editor Type in menu header.

In D4680#107243, @ronan ducluzeau (zeauro) wrote:

@Alberto Velázquez (dcvertice) , I probably misread your comment.
But try to redo your mockup with 3D Cursor using an orientation set to View.
And tell me that is not confusing to have 2 orientation that have nothing in common next to each other.
Mixing things just because these buttons are the ones you use the most, does not make an UI simple to apprehend.
2.80 has now a setting per line with things ordered into subpanels in panels.
But Topbar would be a mess of things that are not affecting same tools.

Yes. And how many default screens are hiding things to new user since that time ? none.
You said that proposal is fine. I disagree.
To get rid of such topbar, user have to know lots of shortcuts for orientation snapping, mode switching but enougho to ignore active tools.
It will not close it.
To get rid of header, he needs to know what is into menus.
So customizing such proposal is just available to intermediate and advanced users.
On the other hand, keeping topbar just for active tool (as it was until now), allows fresh users that began under 2.79b to ignore active tools.

! In D4680#107231, @ronan ducluzeau (zeauro) wrote:
A new user discovering Blender will need everything (menus and popovers).
You already mention the problem of mode that could be hidden if active tool is hidden.
The same way, there is a potential problem of confusion between active tool gizmo orientation (it was move to popover for object gizmos but problem persists for 3D Cursor) and orientation of 3D View that will be used by operators called by a shortcut.

The order of the controls of the proposal should be kept, because mixing the tools with the old header forces to have both header in the viewer always. All this was taken into account when developing the proposal.

In D4680#106931, @Bun ny (bunny) wrote:

It does make sense to move the tool parameters below the menu bar, but for tools with lots of parameters like Sculpt and GPencil these all still feel cluttered. I think putting the Active Tools Settings panel from the Properties editor into some manner of (floating popup?) panel similar to @Alberto Velázquez (dcvertice)'s mockup makes the most sense.
My Sculpt and GPencil workspaces look like this, and I often have to inelegantly slide the area nearly closed to make more canvas space.

In D4680#106528, @Brecht Van Lommel (brecht) wrote:

Testing with buttons shuffled around:

Still doesn't solve the case where in edit mode tool settings don't really have enough space. Also not grease pencil.

Could be a great idea allow one of this tools to add arbitrary mesh. To add objects/meshes to the scene/object easily

Don't waste your time. UI team have ignored all feedback in blender 2.8.

I think that it's better hide the - until user focus on an element. Because a list of - appear more other type of symbol instead a remove symbol.

while a deselect hotkey can be useful, removing the utility of A doing both is a mistake for users who are not going to know that A is capable of doing both and are not going to look for that option. In addition to forcing all former users to retouch the hotkey (this and a hundred other hotkeys) to work as traditional Blender.

In macOS/OSX ⌘ is used like CTRL, SUPER/WINDOWS key doesn't have a lot of uses in windows except for OS shorcuts. But ⌘ is a basic key for anything in macOS and normally is the key that you use for all shorcuts, for example copy&paste is ⌘+C and ⌘+V. Because in macOS you have CTRL but no one uses it in the believe that is hard to use instead the ⌘, something that I think that it's true.

Some Mockups of that idea

In T54951#513749, @Lsscpp (lsscpp) wrote:

Labels going back in the fields?

Mockup

I think that both F3 and the accent is an absolutely hidden shorcut for new users, never in my life I would think of using both of them not for search, but simply for any hotkey, since this is not an FPS that is where that hotkey makes sense. It's hard to think that any user will use taht shortcuts to find something.

I want to remember that in a lot of laptops and almost all apple computers F3 is a really hidden hotkey because you need to press Fn and F3 to have access to F3. Nobody uses this F1-F12 shorcuts because it's a PITA. It's at least 10% of the potential users (20% in USA). Also that few people use F3 to search, it's a common shorcut for really expert users (coders mainly). The mayority of people uses Ctrl+letter (in windows the letter depend of the language of operating system in spain is B, for example).

Use that new feature to the searchbar

In T55162#507550, @William Reynish (billreynish) wrote:

From the start, 2.8 was designed to eschew Wireframe mode as a necessary feature to work in 3D. That's why we've replaced the Z key to enable see-through X-ray mode instead.

I continued working with soc-2017-normal-tools branch and I saw the problem two more times, so I can confirm the bug in the branch. By my work I only use this branch and the error happens one time each ¿4-5 hours? of work. So it's not easy to reproduce. I will try next time that I do a sculpt with dyntopo to use the master branch.

I only see that problems like a feature, If I see the facedot like in that images is because I'm doing something wrong, so it warns when your ngon is not correct for some reason and normally I use facedots like references when I move meshes and I don't need a lot of precision "¿Oh, my cursor is in the same position that the facedot? then I put the cursor correctly". And this happens all days a lot of times. Like incorrect faces that for some reason are created between two faces and don't have any area and facedots tell "hey, you have here a face that you don't want"

I'm modeler and I don't agree with this assessment at all, first of all because it's about deciding for the user and taking away features that currently help him (like select faces that you barely sees, because you select the facedot instead of click in the face) for purely aesthetic reasons.

Hey william