| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
- Remove references to `ISTEXTINPUT` as any keyboard event with it's
utf8_buf set can be handled as text input.
- Update references to the key repeat flag.
|
|
The `ascii` member was only kept for historic reason as some platforms
didn't support utf8 when it was first introduced.
Remove the `ascii` struct members since many checks used this as a
fall-back for utf8_buf not being set which isn't needed.
There are a few cases where it's convenient to access the ASCII value
of an event (or nil) so a function has been added to do that.
*Details*
- WM_event_utf8_to_ascii() has been added for the few cases an events
ASCII value needs to be accessed, this just avoids having to do
multi-byte character checks in-line.
- RNA Event.ascii remains, using utf8_buf[0] for single byte characters.
- GHOST_TEventKeyData.ascii has been removed.
- To avoid regressions non-ASCII Latin1 characters from GHOST are
converted into multi-byte UTF8, when building X11 without
XInput & X_HAVE_UTF8_STRING it seems like could still occur.
|
|
Regression in [0] caused operations such as file-load or file-new
from any window besides the first to write into the freed:
`wmWindow.eventstate`.
Resolve by copying the event instead of restoring the region relative
cursor position after modifying it.
[0]: 789b1617f70e07f1c9bcb5253f1233acacbf6c8a
|
|
|
|
Fix by always testing unhandled double-click events as press events,
irrespective of the previous event type.
**Details**
Handling double-click events only ran when the previously pressed-key
matched the current pressed-key.
Originally when double-click support was added the previous type was
compared (ignoring it's press/release value) and while not necessary
it was harmless as it matched the check for double-click events being
generated.
As of [0] the logic for click/drag detection changed to ignore release
events as release this could interrupt dragging.
This made it possible to generate double-click events that failed the
`event->prev_press_type == event->type` comparison.
In these cases it was possible to generate double-click
events that would not fall-back to a 'press' value when unhandled.
[0]: 102644cb8cbb8b21e55643cebe2ed364885023a6
|
|
- Avoid ambiguity which caused these values to be confused, use `mval`
for region relative mouse coordinates, otherwise `event_xy`.
- Pass region relative coordinates to sample_detail_dyntopo &
sample_detail_voxel as there is no reason to use screen-space values.
- Rename invalid use of mval for screen-space coordinates.
|
|
Wayland doesn't support accessing the position making functionality that
would map events to other windows fail, sometimes considering windows
overlapping when they weren't (as all window positions were zeroed).
Disable dragging between windows when accessing the window the position
isn't supported.
|
|
|
|
|
|
|
|
This allows the use of C++ data structures to simplify code and
improve performance.
|
