Some users mentioned that there's a lag after selecting text
on X11. Tracing through, I saw that the we invalidate the window
quite a lot when dragging the selection, and the buffer swap could
delay for several ms each time while waiting for the vsync.
Rather than blocking the GUI thread and making it bog down, this
commit adopts a technique similar to the recent Wayland frame sync
changes, except that we enforce a minimum of 33ms between frames
in our own scheduler to avoid blocking for several ms at a time.
This seems to do a decent job of balancing responsiveness during
selection with updating the display, and keeps the buffer swap
delay down to microseconds.
We may want to make this delay configurable.
* WIP: IME support for X11
* Handle text generated by IME.
* Set IME position according to the cursor position.
* Improve IME position handling.
Geometry as well as window focus changes are now handled.
* Dispatch IME strings like it's done on windows.
* Make sure not to silently drop IME errors.
* Respect `use_ime` configuration.
* Add xcb-util as dependency.
* Only update IME position if necessary.
* Formatting.
* Update xcb-imdkit-rs.
* Set IME position under the start of the cursor.
This seems to be the way it is commonly done among gui frameworks.
(Tested with Firefox for GTK and Konsole for QT).
* Update xcb-imdkit-rs.
* Handle systems only providing libxcb-util0-dev.
* Add libxcb to freebsd dependencies.
Required by xcb-imdkit-rs.
* Update xcb-imdkit-rs.
* Try to use more recent gcc on centos7.
* More recent C++ compiler on centos7 as well.
* Also setup correct env on centos7 for tests.
transparent images weren't always blending correctly, and were
instead shining through.
This might also have affected cursors.
It may also be a factor in a couple of recent reports of excessive
boldness which looked like funky over-alpha multiplication.
Let's see what people say about this.
This makes the comparison in https://github.com/wez/wezterm/issues/544
work for me on mac, linux (x11, wayland) and also on Windows but
only using WGL.
It looks like we can use the proper colorspace on all targets
except for ANGLE EGL. For whatever reason, the combination of
glium and ANGLE EGL on windows over-gamma corrects.
AFAICT, the framebuffer and perhaps the surfaces it creates
don't indicate srgb support, and whatever combination of status
they return tickles glium's srgb stuff the wrong way.
I think the "solution" is just to directly use WGL by default.
EGL was on by default because it tended to be more survivable
when graphics card drivers were updated, but the last couple
of times I updated mine it still killed wezterm anyway.
refs: #544
The introduction of the Emoji vs Text VS processing means that we might
in some cases not find a glyph with the requested presentation.
In that case, we'd rather show the emoji presentation glyph than none at
all, so we'll retry fallback processing with unspecified presentation.
refs: #997
Add a more general dragging thingy and use that to know when we
are dragging splits or the scroll thumb.
Fixup scrollbar math, which didn't account for whether the tabbar
was shown and which might cause the scroll thumb to jump around
on first drag (resolves#568)
The idea here is to make it a bit easier to do hit detection for UI
elements; today we've been duplicating position math between the render
and the mouse movement handlers, with both pieces of code knowing the
location of the UI element.
UIItem allows the render phase to record the position, which allows
the mouse phase to be a more independent lookup against the registered
elements.
This makes it easier to add more UI elements in the future.
Rather than using the configured initial window size, use the
size of the current tab to size the newly spawned tab.
refs: https://github.com/wez/wezterm/issues/920
