In the worst case this can cause badly implemented desktop components like panels
to constantly rerender and waste 100% CPU (that's how I found a bug in mine :D)
when anything is constantly updating in the terminal (like viewing a log stream).
When using client-side decorations, we can now skip rendering
the header/title bar.
If you've set NONE decorations, then wezterm will configure
the window that way, but that is only respected when the window
is created, as weston crashed when I tried to change this in
a window config reload event.
The wayland frame now also observes config change events,
so frame color adjustments should now take effect without
restarting.
refs: #1077
Changing surface configuration flags *to* default would never be applied.
This was uncovered when implementing increment step resize: it would stop
working after *one* maximization.
The wl_keyboard definition does not define that the incoming fd is always at seek position 0.
In fact, the spec says the fd "can be memory-mapped" and that's it.
And e.g. smithay client-toolkit uses mmap, but we don't :/
Use pread() to read from zero.
This commit introduces a mechanism for specifying resize increments
for a window, and then arranges for the termwindow to set those
to match the current font cell metrics.
This should help to avoid cases where there is excess padding pixels
resulting from the window being slightly larger than computed number
of cells and the font metrics.
Not sure what happened here: presumably a borked merge or something
similar, but this commit allows `window:get_appearance` to return
the actual appearance value on X11.
Even though this plumbs the call through to Wayland, Wayland doesn't
provide an equivalent concept so still always return Light, as is
mentioned on our docs.
closes: #1098
* Trigger a paint immediately from invalidate if not throttled
* Otherwise defer the other events until we're about to sleep for xcb
events, which should maximize the coalesce around resize/expose events
refs: #1051
The thesis is that some WM's might send a whole bunch of events
that cause us to over draw/over resize.
I'm not convinced that this is a righteous change, but it can't
hurt to try.
refs: #1051
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.
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
This commit annotates fonts with a boolean that indicates whether
we think it contains glyphs with emoji presentation, and then
passes the cluster.presentation field down to the shaper.
If the presentation doesn't match the current font in the fallback,
then it will be skipped until we exhaust its options.
`wezterm ls-fonts` also shows whether we think a font has emoji
presentation.
refs: #997
This replaces the slightly gnarly subpixel enabled blending in the
shader with Dual Source Blending, which is a technique where the
fragment shader can specify both the primary color (RGBA) as well
as an additional per-channel mask that can be used to alpha blend
with the destination.
This enables artifact-free alpha blending when used together
with a transparent window background.
refs: https://github.com/wez/wezterm/issues/932
This commit ties our invalidation requests together with the surface
frame callback request so that we can throttle our frame rate if
we're busy, but still remain largely idle if we're not changing
any content.
refs: https://github.com/wez/wezterm/issues/884
https://emersion.fr/blog/2018/wayland-rendering-loop/ suggests that
it is best practice to do this so that the compositor doesn't
cause an application to block forever if the window is moved to
an off-screen state.
That article also suggests using the frame callback to schedule
paints; this commit has that code included, but I've left it
disabled because it causes us to repaint at the monitor refresh
rate which is often more frequently than we would anyway;
in our problem scenario we're painting once per second and we
just want to make sure that that doesn't block.
So hopefully this makes the sway/scratchpad experience better!
refs: https://github.com/wez/wezterm/issues/884
WindowState is a bitfield that can represent maximized, full screen
and hidden window states.
WindowState is passed along with resize events, improving on the
prior basic is_full_screen boolean by representing the other states.
Notably, WindowState::MAXIMIZED is used to represent a state where
the window's size is constrained by some window environment function;
it could be due to the window being maximized in either or both the
vertical or horizontal directions, or by the window being in a tiled
state on any edge.
When the window is MAXIMIZED, wezterm will behave as though
`adjust_window_size_when_changing_font_size = false` because it knows
that it cannot adjust the window size in that state.
This potentially helps with #695, depending on whether the window
manager propagates this state information to wezterm. Gnome/mutter
does a good job at this with both X11 and Wayland, but I couldn't get
sway to report these states and I don't know of any other tiling wm
that I can easily install and use on fedora, so there's a question
mark around that.
Switch to using `xterm` rather than `text` for the name of the
xterm style I-beam mouse cursor, as that appears to be more
compatible across themes; the gnome theme aliases text -> xterm
via a symlink.
Improve error diagnostics in the case that no cursor is found.
refs: https://github.com/wez/wezterm/issues/532
