Slower response of Blender due to click event in "left click" keymap. #68970

Closed
opened 2019-08-21 14:30:44 +02:00 by Alberto Velázquez · 64 comments

Blender2.80 release
Windows 10 (But I suppose that problem is the same in all platforms)

When you use Blender2.80 default keymap with LeftMouse the keymap have a lot of hotkeys using "Click" event instead the "Press" Event. This make blender extremely laggy, specially in edit mesh. User can also don't select some elements if he move the mouse fast. The user experience is completely ruined for users.

  • That event is used in a lot of hotkeys, I can see at least 30 with that event. Main hotkeys like select a vertex, context menu,... all that events are slower (a lot of slower).
  • The problem exist in a lot of parts the keymap, not only in 3D view.
  • I only see the problem in the mouse hotkeys, but I cannot be sure that keyboards don't have it.
  • I didn't test other keymaps like right click or industry standard.

I mention @ideasman42 because he was who decide to don't use the click event by this problem and work in the keymap, and @LazyDodo because he talk about this in devtalk forum.

Blender2.80 release Windows 10 (But I suppose that problem is the same in all platforms) When you use Blender2.80 default keymap with LeftMouse the keymap have a lot of hotkeys using "Click" event instead the "Press" Event. This make blender extremely laggy, specially in edit mesh. User can also don't select some elements if he move the mouse fast. **The user experience is completely ruined for users.** - That event is used in a lot of hotkeys, I can see at least 30 with that event. Main hotkeys like select a vertex, context menu,... all that events are slower (a lot of slower). - The problem exist in a lot of parts the keymap, not only in 3D view. - I only see the problem in the mouse hotkeys, but I cannot be sure that keyboards don't have it. - I didn't test other keymaps like right click or industry standard. I mention @ideasman42 because he was who decide to don't use the click event by this problem and work in the keymap, and @LazyDodo because he talk about this in devtalk forum.

Added subscribers: @LazyDodo, @ideasman42, @AlbertoVelazquez

Added subscribers: @LazyDodo, @ideasman42, @AlbertoVelazquez

#87910 was marked as duplicate of this issue

#87910 was marked as duplicate of this issue

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Campbell Barton self-assigned this 2019-08-21 18:07:45 +02:00

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 #57918 (Tweaks & Fixes for Improved Left Click Select Support (Parent task))

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 #57918 (Tweaks & Fixes for Improved Left Click Select Support (Parent task))

Changed status from 'Archived' to: 'Open'

Changed status from 'Archived' to: 'Open'

Is it a joke? Seriously.

Let's see... I changed all my keymap to "press" instead of "click" and everything works exactly the same but FAST. Exactly the same event that we had in 2.79. In the case that "oh, my God" I select an object at the same time that I make a select box is a problem a thousand times less than the fact of having a lag of 100-200ms at the time of selecting.

Seriously we have thrown ourselves 10 years using left click with "press" event without any problem and now that we get you to do a keymap with left click by default you destroy all the user modeling experience with this nonsense?

https://www.youtube.com/watch?v=2KpFAI3D6TE

You didn't want to use the event "Click" and "click&drag" by default on the keyboard shortcuts because you admitted that it added an unacceptable lag. And it was the keyboard, a secondary input system, not the mouse. And now thousands of users who use left click can work with that without problem? something that if you work quickly makes you lose 20-30% of the clicks? And it's not considered a bug?

How is it working as intended? Is it intended to malfunction?

Is it a joke? Seriously. Let's see... I changed all my keymap to "press" instead of "click" and everything works exactly the same but FAST. Exactly the same event that we had in 2.79. In the case that "oh, my God" I select an object at the same time that I make a select box is a problem a thousand times less than the fact of having a lag of 100-200ms at the time of selecting. Seriously we have thrown ourselves 10 years using left click with "press" event without any problem and now that we get you to do a keymap with left click by default you destroy all the user modeling experience with this nonsense? https://www.youtube.com/watch?v=2KpFAI3D6TE You didn't want to use the event "Click" and "click&drag" by default on the keyboard shortcuts because you admitted that it added an unacceptable lag. And it was the keyboard, a secondary input system, not the mouse. And now thousands of users who use left click can work with that without problem? **something that if you work quickly makes you lose 20-30% of the clicks?** And it's not considered a bug? How is it working as intended? Is it intended to malfunction?

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.

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.

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

Added subscriber: @brecht

Added subscriber: @brecht

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'

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

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.

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.

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 #68970#759388, @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.

> In #68970#759388, @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.

Added subscriber: @ThinkingPolygons

Added subscriber: @ThinkingPolygons

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.

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 #68970#759409, @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...

> In #68970#759409, @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...

Added subscriber: @xan2622

Added subscriber: @xan2622

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.

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.

Added subscriber: @cedriclepiller

Added subscriber: @cedriclepiller

+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!

+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!

Added subscriber: @nokipaike

Added subscriber: @nokipaike

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

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

Added subscriber: @CobraA

Added subscriber: @CobraA

In #68970#759292, @ideasman42 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 #57918 (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 #68970#759292, @ideasman42 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 #57918 (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

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

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

> In #68970#759387, @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 ](https://youtu.be/Tsaa_D6CcSo) in Blender 2.8X family.
Member

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

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

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, 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.
Member

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.

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 #68970#844304, @JulianEisel 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.
LCS BUG.gif

> In #68970#844304, @JulianEisel 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. ![LCS BUG.gif](https://archive.blender.org/developer/F8266556/LCS_BUG.gif)

In #68970#844304, @JulianEisel 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.

> In #68970#844304, @JulianEisel 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

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

Added subscriber: @AndrewPrice

Added subscriber: @AndrewPrice

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

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

In #68970#844304, @JulianEisel 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.

> In #68970#844304, @JulianEisel 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.
Member

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish
Member

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, {nav Shift}-selecting still used the click event, not the press one. This got addressed in 7f794ae09d.

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


In #68970#855523, @AlbertoVelazquez 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.

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, {nav Shift}-selecting still used the click event, not the press one. This got addressed in 7f794ae09d. It also got pointed out that shortest path selection ({nav Ctrl}- and {nav Ctrl+Shift}-selecting) should act on press for the tweak tool as well. I think this is fine, don't see a conflict - @WilliamReynish want to look into that? ---- > In #68970#855523, @AlbertoVelazquez 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.

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

@JulianEisel 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 #68970#855448, @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:

  • select single vertex (was instant all the time)
  • select some vertices (fixed with patch - done)
  • pick shortest path (currently need to be assigned manually in preferences)
  • 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.

изображение.png

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

> In #68970#855448, @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: - select single vertex (was instant all the time) - select some vertices (fixed with patch - done) - pick shortest path (currently need to be assigned manually in preferences) - 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. ![изображение.png](https://archive.blender.org/developer/F8295062/изображение.png) https://developer.blender.org/T70645#855382

Added subscriber: @ThatAsherGuy

Added subscriber: @ThatAsherGuy

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

@JulianEisel 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](https://archive.blender.org/developer/P1221.txt) (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](https://archive.blender.org/developer/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)

> 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)

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

@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 ](https://developer.blender.org/diffusion/B/browse/master/source/blender/windowmanager/intern/wm_event_system.c$2868) 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 #68970#856976, @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.

> In #68970#856976, @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.

Removed subscriber: @CobraA

Removed subscriber: @CobraA

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

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.

изображение.png

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. ![изображение.png](https://archive.blender.org/developer/F8302169/изображение.png)

Added subscriber: @Znio.G

Added subscriber: @Znio.G

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.

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 #68970#871878, @Znio.G 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 #68970#871878, @Znio.G 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 #68970#871939, @1D_Inc wrote:

In #68970#871878, @Znio.G 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 #68970#871939, @1D_Inc wrote: >> In #68970#871878, @Znio.G 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 #68970#872151, @Znio.G 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.

> In #68970#872151, @Znio.G 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.

Added subscribers: @Vyach, @PratikPB2123

Added subscribers: @Vyach, @PratikPB2123

So… the topic is old. The issue is known.
The solution known too
So why there is still «clicks» and slowdowns?

It is not hard to fix keymap.
And I don`t see any reason to keep clicks.
Do you? Anyone?

So… the topic is old. The issue is known. **The solution known too** So why there is still «clicks» and slowdowns? It is not hard to fix keymap. And I don`t see any reason to keep clicks. Do you? Anyone?

In #68970#1153959, @Vyach wrote:
Anyone?

Well, let me try.
As Julian said:

In #68970#844304, @JulianEisel 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.
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.

In short, click behavior is needed for things like box select, and the only problem left was proper complete tweak tool defaults setup:

In #68970#855657, @JulianEisel wrote:
It also got pointed out that shortest path selection ({nav Ctrl}- and {nav Ctrl+Shift}-selecting) should act on press for the tweak tool as well. I think this is fine, don't see a conflict - @WilliamReynish want to look into that?

William replied that complete tweak remap is also not a problem, but the decision must be made:

In #68970#855779, @WilliamReynish wrote:
@JulianEisel 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.

So the decision to remap tweak tool defaults for loop select and pick shortest part shortcuts both for 3D View and UV Editor is still pending.

> In #68970#1153959, @Vyach wrote: > Anyone? Well, let me try. As Julian said: > In #68970#844304, @JulianEisel 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. > 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. In short, click behavior is needed for things like box select, and the only problem left was proper complete tweak tool defaults setup: > In #68970#855657, @JulianEisel wrote: > It also got pointed out that shortest path selection ({nav Ctrl}- and {nav Ctrl+Shift}-selecting) should act on press for the tweak tool as well. I think this is fine, don't see a conflict - @WilliamReynish want to look into that? William replied that complete tweak remap is also not a problem, but the decision must be made: > In #68970#855779, @WilliamReynish wrote: > @JulianEisel 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. So the decision to remap tweak tool defaults for loop select and pick shortest part shortcuts both for 3D View and UV Editor is still pending.

! In #68970#1154126, @1D_Inc 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.

Nope. Tweak tool have exact same issue now. If tweak tool will fix an issue and select with press it will be better way: tweak — priority to selection, another tool — priority to action.

Also. Loop select works with alt and shift. Not just with press

but at what point does it become silly to add dozens of operators inside this tool

No need to make dozens operations. It needs one override as option (on by default)

So the decision to remap tweak tool defaults for loop select and pick shortest part shortcuts both for 3D View and UV Editor is still pending.

So «we need to talk» :)

>! In #68970#1154126, @1D_Inc 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. Nope. Tweak tool have exact same issue now. If tweak tool will fix an issue and select with press it will be better way: tweak — priority to selection, another tool — priority to action. Also. Loop select works with alt and shift. Not just with press >but at what point does it become silly to add dozens of operators inside this tool No need to make dozens operations. It needs one override as option (on by default) >So the decision to remap tweak tool defaults for loop select and pick shortest part shortcuts both for 3D View and UV Editor is still pending. So «we need to talk» :)

In #68970#1154233, @Vyach wrote:
If tweak tool will fix an issue and select with press it will be better way: tweak — priority to selection, another tool — priority to action.

Well, this is general weakness of industry standard approach.
Selection tool > selection > Action tool > action > tools options order cause problems because any kind of editing is built around selection anyway,
so Blender provided another approach to this problem, that works in more natural way, which is more logical and compact, so it allowed to compress all this ISS approach stuff into a single tweak tool
Selection > Selection/Action tool > tools options (snaps toggles, axis toggles and so one)

That's why when you try to put industry standards to Blender it is so clunky - it never worked properly at a concept level all this time in other software, so you have to build a lot of expensive workarounds during UI/UX/workflow design and make a lot of unnecessary movements when working with it, for example an endless switching between the selection tool and the action tool.

So, Industry standards are always expensive in design and less effective in use than Blender's approach, because it has a problem at a conceptual level, but it was easier to learn, because it rely on a graphical interface,
especially in the days before the Internet and especially before YouTube - internet videos with sound notations.

> In #68970#1154233, @Vyach wrote: > If tweak tool will fix an issue and select with press it will be better way: tweak — priority to selection, another tool — priority to action. Well, this is general weakness of industry standard approach. **Selection tool > selection > Action tool > action > tools options** order cause problems because any kind of editing is built around selection anyway, so Blender provided another approach to this problem, that works in more natural way, which is more logical and compact, so it allowed to compress all this ISS approach stuff into a single tweak tool **Selection > Selection/Action tool > tools options (snaps toggles, axis toggles and so one)** That's why when you try to put industry standards to Blender it is so clunky - it never worked properly at a concept level all this time in other software, so you have to build a lot of expensive workarounds during UI/UX/workflow design and make a lot of unnecessary movements when working with it, for example an endless switching between the selection tool and the action tool. So, Industry standards are always expensive in design and less effective in use than Blender's approach, because it has a problem at a conceptual level, but it was easier to learn, because it rely on a graphical interface, especially in the days before the Internet and especially before YouTube - internet videos with sound notations.

For me it is just logical: at first I select something independent from tool I choose, then I do something with tool or change tool and do.
And priority should go same order.
Selection IMO shouldn`t be a tool, because it can be used with any tool, or action, operator, macro, overlay…

So: tool shouldnt hav priority over selection and selection shouldnt be a tool (most time at least).

For me it is just logical: at first I select something independent from tool I choose, then I do something with tool or change tool and do. And priority should go same order. Selection IMO shouldn`t be a tool, because it can be used with any tool, or action, operator, macro, overlay… So: tool shouldn`t hav priority over selection and selection shouldn`t be a tool (most time at least).

It is a conflict between popular standard and good approaches.
Anyway, at the moment we can only hope to fix the tweak tool defaults.

It is a conflict between popular standard and good approaches. Anyway, at the moment we can only hope to fix the tweak tool defaults.

In #68970#844304, @JulianEisel 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.

This also does not solve the problem - it is not clear why tweak is still not set by default in Blender.
There are no provements that Box selection by default is better or even useful - because after box selection you always have to make some action, switching from selection tool to the real action tool, like tweak tool.
This happens every single time, so it is not clean how it was supposed to be used - box, circle and lasso are deeply secondary in comparison with tweak.
The very first action after using box selection is always not using box selection.
If to take into account clunky click behaviour, as a result we have useful option left behind and broken, and useless function set to default, which means that defaults are not useful.

> In #68970#844304, @JulianEisel 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. This also does not solve the problem - it is not clear why tweak is still not set by default in Blender. There are no provements that Box selection by default is better or even useful - because after box selection you always have to make some action, switching from selection tool to the real action tool, like tweak tool. This happens every single time, so it is not clean how it was supposed to be used - box, circle and lasso are deeply secondary in comparison with tweak. The very first action after using box selection is always not using box selection. If to take into account clunky click behaviour, as a result we have useful option left behind and broken, and useless function set to default, which means that defaults are not useful.

I will tell simplier.
I hate boxselect tool as default.
And there is no need to swithch to it with mouse, because I have B.

And even more I hate, that every new area/screen switch to it again and again. When I create it, instead just inherit tweak, that I set before for this area.
Extremely annoying thing…

2021-05-12_01-05-31.mp4

I will tell simplier. I hate boxselect tool as default. And there is no need to swithch to it with mouse, because I have B. And even more I hate, that every new area/screen switch to it again and again. When I create it, instead just inherit tweak, that I set before for this area. Extremely annoying thing… [2021-05-12_01-05-31.mp4](https://archive.blender.org/developer/F10083288/2021-05-12_01-05-31.mp4)

Well, there are practical reasons if you hate it, because it make defaults efficiency lower.

Box select is one of thins that was implemented to satisfy max and maya users, I guess.
They are not familiar with Selection>action paradigm, created in Blender and not presented in the industry standards, and they are not familiar with advantages of B/C selection, when selection tool is secondary and can be invoked at any time immediately just like any other tool.

B/C It is better solution than industry standard, but it take some time to get it when you switch from max/maya to Blender. I remember it was annoying a bit when I was switching from another paradigm to Blender, but it desrves to be learned because of better overall efficiency and speed.

Well, there are practical reasons if you hate it, because it make defaults efficiency lower. Box select is one of thins that was implemented to satisfy max and maya users, I guess. They are not familiar with Selection>action paradigm, created in Blender and not presented in the industry standards, and they are not familiar with advantages of B/C selection, when selection tool is secondary and can be invoked at any time immediately just like any other tool. B/C It is better solution than industry standard, but it take some time to get it when you switch from max/maya to Blender. I remember it was annoying a bit when I was switching from another paradigm to Blender, but it desrves to be learned because of better overall efficiency and speed.

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art

Nice example of a 3dsmax-related workflow - selecting every single vertex with box selection to tweak it with gizmo.
Every single time.
This is the way that was usually learned from 3dsmax, now it is learned from Blender.

https://youtu.be/4nh-fXe9QOg?t=64

Nice example of a 3dsmax-related workflow - selecting every single vertex with box selection to tweak it with gizmo. Every single time. This is the way that was usually learned from 3dsmax, now it is learned from Blender. https://youtu.be/4nh-fXe9QOg?t=64
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
17 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#68970
No description provided.