@kalgynirae showed me weirdly laggy behavior when moving the mouse
in front of his x11 window. My suspicion was that this is somehow
related to updating the mouse cursor glyph, and looking at this code
there were two things that might influence this:
* We weren't saving the newly applied cursor value, so we'd create
a new cursor every time the mouse moved (doh!)
* We'd create a new cursor id each time it changed, and then destroy it
(which isn't that bad, but if it contributes to lag, maybe it is?)
This commit addresses both of these by making a little cache map
from cursor type to cursor id.
I can't observe a difference on my system, so I wonder if this might
also be partially related to graphics drivers and hardware/software
cursors?
Hiding a window is implemented as miniaturizing the window, which
is typically shown with an animation of the window moving into the
dock.
This is not the same as the application-wide hide function in macOS;
that function hides the entire app with no animation. We don't use
that here because our Hide function is defined as a window operation
and not an application operation.
refs: https://github.com/wez/wezterm/issues/150
The opengl based render first clears the window to the background
color and then renders the cells over the top.
on macOS I noticed a weird lighter strip to the bottom and right of
the window and ran it down to the initial clear: our colors are SRGB
rather than plain RGB and the discrepancy from rendering SRGB as RGB
results in the color being made a brighter shade. This was less
noticeable for black backgrounds.
Remove a normalizing function that made assumptions based on the
keycaps that did not hold up when selecting Dvorak as an input
source. For example "CTRL-C" where `C` is the key with the C keycap
would send `CTRL-C` even when Dvorak was selected; it should send CTRL-J
in that layout.
I think with the other normalization that happens in the termwindow
layer we don't need this function any more.
The default values are 3 lines. With this change, scrolling speed now seems
similar to other programs like cmd.exe. Before this change it feels too slow.
I noticed my trackpoint or touchpad reports a lot of < 120 (WHEEL_DELTA) events.
They shouldn't be ignored.
Also https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel says:
> The wheel rotation will be a multiple of WHEEL_DELTA, which is set at 120.
> This is the threshold for action to be taken, and one such action (for
> example, scrolling one increment) should occur for each delta.
>
> The delta was set to 120 to allow Microsoft or other vendors to build
> finer-resolution wheels (a freely-rotating wheel with no notches) to send
> more messages per rotation, but with a smaller value in each message. To use
> this feature, you can either add the incoming delta values until WHEEL_DELTA
> is reached (so for a delta-rotation you get the same response), or scroll
> partial lines in response to the more frequent messages. You can also choose
> your scroll granularity and accumulate deltas until it is reached.
macos generates fractional distance values for the mouse wheel,
with one tick starting at 0.1. We were truncating this to a 0 row
move, which meant that you'd need to build up some acceleration to
move the rows when all you really wanted was a single tick.
This commit changes things so that we round up to at least 1.0 in this
situation.
The IME stuff on macos tends to swallow repeats for some keys.
Ugh. So this commit adds an option to disable the use of the IME.
Switching away from it effectively inverts the meanging of backspace
and delete (because our method is no longer called by the IME), so
we need to check for that and remap it. Ugh.
Ugh.
double clicks weren't registering correctly with the new selection
logic. Tell windows that we're doing all our own click counting
and simplify the logic.
Force using xcb-util 0.2.1 precisely because 0.2.2 pulls in a
conflicting major version of xcb (0.8 -> 0.9).
It's a non-trivial upgrade: the types around xkb are different
and features need to be specified in the manifest to enable compilation
of the things that we depend upon.
In addition, xkbdcommon, on which we depend, requires xcb 0.8 and
results in pulling in two conflicting versions of the crates.
It's a bit of a painful situation and will require some effort to
figure out how to upgrade the xcb dependency, when we're ready for that.
refs: https://github.com/meh/rust-xcb-util/issues/12
On x11 we'd get just a single line per scroll wheel tick.
Contrast with Wayland where we get multiple.
This config change makes us feel more snappy by default on X11.
I'd like to make this configurable using the live configuration
infra, but we don't currently have a way for this crate to see
that config, so this just changes the default to be "better".
refs: https://github.com/wez/wezterm/issues/92
This reverts commit bfa8d0c207,
which proved not to be needed because it was already covered
by the `KeyboardEvent::Enter` and `KeyboardEvent::Leave` handling.
On a Fedora 31 system running Wayland I noticed that wezterm and
the compositor were running pretty hot on their respective CPU
cores.
It turned out that we had a lot of
[Refresh](https://docs.rs/smithay-client-toolkit/0.6.4/smithay_client_toolkit/window/enum.Event.html#variant.Refresh)
events being generated and consumed. We were treating this as needing
a full paint so we'd be effectively continually running the opengl
paint cycle over and over.
The docs for that event say that it is intended to refresh the client
decorations so let's focus it towards that instead. This does bring
the CPU usage back down to intended levels.
I believe this hot CPU usage to be compositor-dependent: this is the
first I've seen of it out of 4 different Wayland environments!
1f81a064ed added support for noticing
that the dpi scale was not 1 on startup, but the timing of this
signal was different between the opengl and software renderers.
When using the software renderer, we'd end up computing a scaling
change with a pre-change pixel size but adjusted by a post-post
scaling factor, and that effectively caused the window to halve
its size on startup.
This commit improves things by also tracking the dpi in our locally
stored dimensions.
@sunshowers mentioned to me that the window appeared blurry on a hidpi
display on startup, and was fixed by changing focus in a tiling window
manager.
I could replicate this using weston with scaling set to 2; the issue was
that the initial scale factor change event wasn't fully propagated and
bubbled up as a resize event to the terminal layer.
This commit taps into the dpi change event and forces it to be
interpreted as a window configuration change, resulting in more crisp
text.
