This repository has been archived on 2023-10-09. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Sergey Sharybin ca1daf4cda Fix an increasing bottleneck when key press operator is too slow
The goal of this change is to fix an increasing bottleneck of the event
queue handling when there is an operator bound to a key press event and
is taking longer to finish than a key-repeat speed on the system.

Practical example of when it happens is the marker tracking operator in
a single-frame track mode. Quite often artists will hold down Alt-arrow
to track a segment of footage which seems trivial to track. The issue
arises when the Alt-arrow is released: prior to this change it is was
possible that more frames will be tracked. It also seems that redraws
are less smooth.

It is a bit hard to make easily shareable computer-independent test
case. Instead, a synthetic case can be reproduced by adding a 50 ms
sleep in the `text_move_exec()`. In such synthetic case open a long
text in the text editor and hold left/right arrow button to navigate
the cursor. The observed behavior is that seemingly redraws happen
less and less often and cursor travels longer and longer distances
between redraws. The cursor will also keep moving after the buttons
has been released.

The proposed solution is to ignore sequential key-press events from
being added to the event queue. This seems to be the least intrusive
and the most safe approach:

- If the operator is fast enough there will be no multiple press events
  in the queue in both prior and after of this change.

- If the operator is slow enough, clicking the button multiple times
  (i.e. clicking arrow button 3 times in a heavy shot will change the
  scene frame by exactly 3 frames because no events are ignored in
  this case).

- Only do it for key press events, keeping mouse and tabled behavior
  unchanged which is crucial for the paint mode.

Note that this is a bit different from the key repeat tracking and
filtering which is already implemented for keymaps as here we only want
to avoid the event queue build-up and do want to ignore all repeat
events. In other words: we do want to handle as many key presses as the
operator performance allows it without clogging anything.

A possible extension to this change could be a key press counter, so
that instead of ignoring the event we merge it into the last event in
the queue, incrementing some counter. This way if some operator really
needs to know exact number of key repeats it can still access it.

Differential Revision: https://developer.blender.org/D15444
2022-07-15 11:03:00 +02:00
2021-10-23 10:49:51 +05:30
2022-06-29 10:19:02 +10:00
2021-03-26 16:15:02 +01:00
2010-10-13 14:44:22 +00:00
2022-01-25 09:19:03 -07:00
2022-06-28 15:56:16 +02:00

Sphinx Warnings

: WARNING: Could not obtain image size. :scale: option is ignored.

Note the preview is not accurate and warnings may not indicate real issues.

Blender

Blender is the free and open source 3D creation suite. It supports the entirety of the 3D pipeline-modeling, rigging, animation, simulation, rendering, compositing, motion tracking and video editing.

https://projects.blender.org/archive/blender-archive/media/commit/ca1daf4cdaaa9a806869586efe6a752b502c156c/https://code.blender.org/wp-content/uploads/2018/12/springrg.jpg

Project Pages

Development

License

Blender as a whole is licensed under the GNU General Public License, Version 3. Individual files may have a different, but compatible license.

See blender.org/about/license for details.

Description
Archive of Blender with old branches
Readme 823 MiB
Languages
C 67.4%
C++ 23.4%
Python 6.1%
CMake 1.5%
GLSL 1.1%
Other 0.4%