This should be a very small value - otherwise the users might move the cursor slightly to select a different item - instead of selecting what is now under the cursor - it will select the *next* item from all items near the cursor.

Would rather avoid a preference - although we could have one which is the distance allowed before the cursor is considered to have moved. (different from drag distance).

How many times I see this happening.
I kinda agree with @Reinis Adovics (kroko) W should activate context menu both in Left and Right keymaps, there's not a relevant point on making this seemingly random distinction between keymaps. It only makes harder for users who learn different keymaps to talk about the same thing.

all the numbers start bigger than 1ms, then they quickly converge to small usual values before I have a chance to take a screenshot, not sure if its the sampling accumulating or actual times.
But those stats don't seem to follow the viewport lag.

@Campbell Barton (campbellbarton), @Brecht Van Lommel (brecht)
sorry annoying you guys, I wish I could get a second review on this. This is not such a big feature but I really believe it could make blender sculpting more competitive.
For some reason, some reviews neither get rejected nor approved, just stay stagnated.

The animator doesn't need to see the whole path all the time, its like onion skin, so this could be solved by limiting the number of frames evaluated, adding a start_clip and end_clip, maybe even with a pretty fading gradient.

I'm not sure it's really deprecated, since those are comments from 10 years ago. @Joshua Leung (aligorith) would know what the status is here I think. Maybe ghost drawing needs to be restored in 2.8, and the comments updated?

The reverse is also true. If you enable Symmetry, and switch to a different object, you'll accidentally then start to manipulate it without Symmetry, because the tool setting was forgotten, because it is now a different mesh. That is equally as annoying. This is my point: There are cases where you may want to use it only with certain objects, and there are other cases where you won't. And that applies to any tool setting.

If Symmetry is really going to be per object, we should do so consistently in all modes, and display it in the ObData Properties.

But, the most consistent solution is simply to make it a mode-wide tool setting, and make it work the same in Edit Mode, Sculpt Mode and the paint modes. There's no difference in use-case, and no logical reason why they should work differently in the various modes.

Jan 9 2019

Hey, I wanna make a patch and submit for review but this problem is happening when I try to build blender for debugging.
I wanna make some changes to sculpt.c, should I just ignore or it can cause problems?

Dec 16 2018

Thanks for a good answer, now, I can understand a bit what happened, the fact that a thing designed to display global settings is being used to display local properties, is really alkward.
,A per-editor bar doesn't exclude topbar, it moves local settings like tools into it, while topbar can keep the global mode-related settings.
Many users are concerned that it's too disconnected from the editors when working with multiple splits in the screen, the topbar switch like crazy and is seemingly disconnected from the editors that it inherits settings from.

Its just a guess but there's something wrong with the shadow computation when its multiplyied by the reflection, seems like its not completelly zero allowing verry bright spots to "LEAK" when lamps are too strong.

I tried with both Firefox and chrome, and the bug happens exactly the same, since I disabled hardware acceleration on chrome and it happens exactly like in Firefox which have acceleration enabled, I guess it's not a hardware specific problem neither software specific.