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.

So mybe you gt the idea of wat yu re defendng.

It's a down-side, I'm not defending it - however you are re-raising a topic that was closed months ago.

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

Seriously, this destroy all the blender2.8 LeftClick user experience, all the fluidity of the program,... to avoid a down-side that is a thousand times less problematic.

I have spent months thinking that Blender2.8 was slow selecting and it was the fault of the new viewport and that it would be fixed in the final bug-fixing. I've been 2-3 months without using blender2.8 and I haven't verified that this was still happening. Now, after a vacation, I have returned to the program and I only need a few objects to see that simply modeling is going badly.

It is not important that this was discussed months ago and a very bad decision was made. If a bad decision was made it should not be the user who must suffer for years until Blender4.5 arrives as happened with many other decisions of UX.

And It's not a joke or exaggeration. I've always been going around the codequest and I've been a very critical person, that's true but I told this seriously, this is the biggest mistake I've seen in 2.80 about UX. get together, talk about it and change it.

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.

How can you not consider a bug to have a default setting that makes you fail 1 out of every 3 vertices you select?

It's worse than having a crash.

You can't expect us to start talking in devtalk, reach a consensus, see how many likes each comment has and then make a decision.

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

It is normal, you are part of the minority that uses a cintiq to model and needs to have all the menus on the right side because moving the hand tires you. The only thing you make clear with that comment is that you don't model habitually and that you are really slow in your work.

That problems happens if a user select one or two vertices. The problem is the speed, not the number of vertex. And use constantly the circle when you can make two mouse clicks...

I have also noticed this slow-down while using the selection box while the event is set to "Click". After a while it gets annoying. This is undoubtedly a regression.

If I change the event to “Press” (in Keymap > 3D view > 3D view (Global) > Select), the selection is faster, it's obvious.

+1 it's a BIG BUG!

When moving points on retopo for example, having to wait is BAD and you want to move them one by one contrary what ThinkingPolygons said.

Make it work correctly, it's a bug!

sometimes we need to be flexible and pragmatic, if something improves the user experience we should give priority to this ...
this is what improves the software, this is what makes it appreciable and fun more and more ..
when it works as expected. (or how users are used to how it has always worked well.)

In T68970#759292, @Campbell Barton (campbellbarton) wrote:

Many applications that use left click select, select on click not press.

This is a down side of left click select in general, since you may want to border select on drag, and pick the object under the cursor on click.

This is working as intended, since making left click select keymap work on press would require a re-design. See T57918: Tweaks & Fixes for Improved Left Click Select Support (Parent task)

In Maya it's instantaneous for both selection and border select, well at least visually but in Blender the gizmos feels like they drag behind for mil seconds, same when moving the object in the viewport or navigating, there seems to be a slight delay........is this an issue for upadating the viewport or maybe there is a threshold??
https://devtalk.blender.org/t/will-be-perfomance-a-main-target-in-2-81/8548/77

In T68970#759387, @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.

There are 3 types of feedback possible - Bug, Workflow Issue and Proposal.
Here is the difference between them:

• Bug is about a nice roadmap feature design but bad realization. Bugs can make software unusable by making unstable.
• Workflow issue is about bad roadmap feature design. Workflow issues can make software unusable directly.
• Proposal is about feature that can make software better. Proposals are about possible software progress.

The problem is that workflow issues can be as deadly as bugs, but most of them are currently defined as proposals. They are not yet divided into a special category.
This topic is not about a software bug, but a serious workflow issue, that ruins the ability of making complex organic modeling and retopology in Blender 2.8X family.

Like Campbell said, this is a design that's meant to avoid conflicts. Both action and selection are on the left mouse button now (unlike in 2.7, even with LCS) - how do we know if a mouse press intended to select, or execute the active tool action, like box-select? The click event allows differentiating.
To be clear: I'm not saying the complaints about this are invalid, just emphasizing again that this is a compromise that had to be accepted. It's very annoying that it backfires so much for a workflow like fast modelling, but it does improve others.

To get the previous default behavior back, you can enable the tweak tool. It selects on press, and translates the new selection on tweak. That's how 2.7 behaved by default and should solve the issues raised here.

@CobraA (CobraA), this is a different issue. There could be multiple bottlenecks: E.g. viewport drawing, transform operator, depsgraph. My guess is that it's the latter. We also do an UI optimization which may cause this though: When the mouse moves many pixels fast-ish, we merge multiple movement events into a single one, to reduce updates. That may make it appear like it wasn't following the cursor correctly.
Could also be a combination off all these factors.

BTW, if you prefer the tweak tool behavior to be the default, you can simply enable it in your modelling workspace(s) and save the startup file. It will then remain your default tool for these workspaces.

In T68970#844304, @Julian Eisel (Severin) wrote:

To get the previous default behavior back, you can enable the tweak tool. It selects on press, and translates the new selection on tweak. That's how 2.7 behaved by default and should solve the issues raised here.

That's the actual problem - It should but it doesnot.
That's we are talking about and showing on all those videos and GIFs.
https://developer.blender.org/T70645

Tweak tool behaves the same as box select tool - the only difference is that it don't make box selecting, but have a limitations like it have box selecting.
We asking for making tweak tool behave differently from box select tool, to remove those limits for it, to provide the ability of fast and confident selection.
To make a real tweak tool with nice LCS selection.

Here is an else another GIF about this issue (click on it to see)
2.82 (sub 3), branch: master, commit date: 2019-12-03 17:56
Tweak tool is on, all modes (press/click/release) behaves the same, RCS selects vertices just immediately and confidently at any circumstance while LCS waits until mouse wil stay strightly still, ignoring mouse clicks.
I never used RMB for modeling, but with current tweak tool RCS behavior is several times better than LCS.

In T68970#844304, @Julian Eisel (Severin) wrote:

this is a different issue. There could be multiple bottlenecks: E.g. viewport drawing, transform operator, depsgraph. My guess is that it's the latter. We also do an UI optimization which may cause this though: When the mouse moves many pixels fast-ish, we merge multiple movement events into a single one, to reduce updates. That may make it appear like it wasn't following the cursor correctly.
Could also be a combination off all these factors.

Well then i hope you guys investigate these important issues, I know it's easier said than done for such complex problems but hopefully they're on your future plans.

Important!
It seems, we found a solution!
https://developer.blender.org/T70645#846661

What's the verdict on the above post? Can it be fixed?

In T68970#844304, @Julian Eisel (Severin) wrote:

Like Campbell said, this is a design that's meant to avoid conflicts. Both action and selection are on the left mouse button now (unlike in 2.7, even with LCS) - how do we know if a mouse press intended to select, or execute the active tool action, like box-select? The click event allows differentiating.

It's a decision to avoid conflicts that create more conflicts and problems that try to solve.

What I said above still holds up, to get the old selection behavior back (at least for most interactions), the tweak tool has to be activated.
There was however an oversight, that is, Shift-selecting still used the click event, not the press one. This got addressed in rB7f794ae09d25.

It also got pointed out that shortest path selection (Ctrl- and Ctrl+Shift-selecting) should act on press for the tweak tool as well. I think this is fine, don't see a conflict - @William Reynish (billreynish) want to look into that?

In T68970#855523, @Alberto Velázquez (dcvertice) wrote:

It's a decision to avoid conflicts that create more conflicts and problems that try to solve.

The distinction between clicking and dragging is hugely important for LCS and the entire active tool design. Without it, it would barely be a usable design (e.g. we couldn't allow mouse-selecting while a non-selection tool is active).
Yes it does bite back in some cases, and yes, in some workflows much more than in others. Each design has it's trade-offs, but as I explained there are simple workarounds for these in place.

@Julian Eisel (Severin) We should indeed be able to add those to the Tweak tool without a conflict, but at what point does it become silly to add dozens of operators inside this tool? Not sure that's acceptable? I could easily add them of course, if we think it's necessary.

In T68970#855448, @Andrew Price (andrewprice) wrote:

What's the verdict on the above post? Can it be fixed?

Yes, first patch has been applied and it already fixing Shift+LCS for Tweak tool in 2.83 alpha build.
Works like a charm!

There are 4 common types of a selection, used in hardsurface modeling:

1. select single vertex (was instant all the time)
2. select some vertices (fixed with patch - done)
3. pick shortest path (currently need to be assigned manually in preferences)
4. loop selecting (is not critical)

So, Shift+LCS is fixed, Ctrl+LCS and Shift+Ctrl+LCS (pick shortest path) are left.

It is also possible to tweak also Alt+LCS for loop selection, but it is not that critical, because basically it is necessary to keep the mouse still for the right edge selection during the work, therefore it does not slow down the whole work process much.
I've tried both Alt+LCS setups for high loop selecting workflow (wicker modeling - every rod tweaking requires a loop selection), it brings some inconvenience with selection decline because of default hand shaking, but not like Shift, Ctrl and Ctrl+Shift, so it is more nice to have than must have.
It is useful for wicker/ropes type of modeling.

https://developer.blender.org/T70645#855382

@Julian Eisel (Severin) Right now there isn't a fallback for un-handled click-drag events; they slide away into the ether when we could be treating them as click events. I'd rather see something like P1221 (tweaked to send the key release coordinates instead of the key press coordinates; if we need the press coordinates for a click event we can use prevclickx and prevclicky) than a band-aid solution that relies on overloaded tool keymaps.

There are some other options I'd like to explore as well, once D5153 is approved. The Win32 implementation should be a breeze, and I haven't spotted any major roadblocks that'd impact an OS X implementation; we just need the green light from you.

tweaked to send the key release coordinates instead of the key press coordinates;

I am not sure that it should be so complicated at this point.
We are discussing adding a couple of rows to a keymap, which will completely solve the critical usability issue that lasts more than a year.

But this proposal looks like fullscale OS dependent core developement research, a huge difference)

@Paul Kotelevets (1D_Inc) Press and release events are turned into click events in wm_event_system.c, long after the platform-specific stuff is taken care of. All we'd have to do is trim a few lines here to make it work. It'd give us more information to work with in modals, since we wouldn't be overwriting the release location with press data that's already accessible through the event system, and it'd match how the vast majority of operating systems handle click events (in the 3D viewport; the UI handlers have their own logic).

In T68970#856976, @Asher (ThatAsherGuy) wrote:

It'd give us more information to work with in modals, since we wouldn't be overwriting the release location with press data that's already accessible through the event system, and it'd match how the vast majority of operating systems handle ...

For sure, but it will influence everything, so that means, that entire software will be required to be tested.
It is a huge amount of work with unpredictable crossplatform result. It is very important, but is not urgent.

It would be nice to first solve the problem using a well-known, simple and already working method, to cover today's production needs, and after that start that kind of a deep research, to give artists the opportunity to make a hardsurface modeling during research, if it is possible.

Made proper video with workflow comparison and setup
https://youtu.be/MVCpRuOlqVo

I tested the solution for a while in practice.
Yes, indeed, Alt+LCS and Alt+Shift+LCS are also needed to be fixed.
There is actually no reason to keep any kind of clunky selection for the tweak tool.

I personally had to change every tool and operator event to make my own custom keymap, the problem i faced everytime is whenever there are new changes added to Blender, they affect the keymap and you have to re do it all over agin.

the Input editor doesn't make it easy to work with either, So my suggestion instead of maybe adding another global option or changing the default, the solution should be on how we can make custom keymaps easily without having to do it from scratch each time and keep that consistent across Blender's version not matter how small or big the updates.

In T68970#871878, @Zino Guerr (Zino) wrote:

I personally had to change every tool and operator event to make my own custom keymap

For sure. We also do this every time, (but we change operators only from version 2.8)

and keep that consistent across Blender's version not matter how small or big the updates.

That would be nice, but it will bring too much limits to a development process.
Requests cause structural changes to the key map, the toolkit is constantly changing, so these changes occur.
To make viable solid keymap core, devs should at least take into account every workflow, including complex one, that will be a years of research and hundreds consultations, and develop to its final stage every tool that will require keymap.
Not sure if this is possible.

In T68970#871939, @Paul Kotelevets (1D_Inc) wrote:

In T68970#871878, @Zino Guerr (Zino) wrote:

I personally had to change every tool and operator event to make my own custom keymap

For sure. We also do this every time, (but we change operators only from version 2.8)

and keep that consistent across Blender's version not matter how small or big the updates.

That would be nice, but it will bring too much limits to a development process.
Requests cause structural changes to the key map, the toolkit is constantly changing, so these changes occur.
To make viable solid keymap core, devs should at least take into account every workflow, including complex one, that will be a years of research and hundreds consultations, and develop to its final stage every tool that will require keymap.
Not sure if this is possible.

Not really, revamping the input editor would be a good start than they can build from that point.
It's the extensibility that it's a bit hard, most people would make some changes to the default keymaps once they're comfortable with Blender, I have seen many complains about the issue of breakage between versions.
I think the Devs can figure out a good middle solution without taking years of research,they're more capable in development then we are :).

In T68970#872151, @Zino Guerr (Zino) wrote:

Not really, revamping the input editor would be a good start than they can build from that

I think the Devs can figure out a good middle solution without taking years of research,they're more capable in development then we are :).

Well, we are kinda trying to get normal vertices selection here instead of broken for a year, to start modeling.
Let's not push it that far.