It seems like this is making things worse on X11/Wayland.
Let's try simply skipping it--that seems fine on X11/Wayland,
but needs to be verified on macOS and Windows.
refs: #1002
refs: #695
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
The intent is to avoid weirdness with Wayland where we need to wait for
a configure event before we try to set the window size programmatically.
refs: #1002
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.
This commit changes the full surface fill to be fully transparent,
and adds a separate quad to fill with the configured window background
color.
The thesis is that this should avoid the apparent weird rgb/srgb
mismatch that seems to occur with the window background on Intel macs
(those have a different OpenGL implementation than M1 based macs which
don't appear to have this issue).
refs: https://github.com/wez/wezterm/issues/1000
refs: https://github.com/wez/wezterm/issues/653
I noticed that on macos, the initial terminal size didn't
match the 80x24 default; it was a few columns short.
I think I broke this with recent changes in window
event dispatching.
This commit passes the terminal size down to apply_dimensions
just after we've set up the GL context to preserve the
terminal size.
Possibly related to https://github.com/wez/wezterm/issues/1002
An implementation detail in wezterm is that it doesn't model
image placements as a separate entity; they are all bound to
the image cells in the terminal model.
The semantics of the kitty image protocol are that placements
are "permanent" wrt. overwriting a cell with text, except for
the explicit EraseInLine/EraseInDisplay sequences that are
used for clearing.
This commit takes a pass at implementing that semantic in
the wezterm data model.
refs: #986
This should help to avoid artifacts in the case where glyphs
render outside their nominal terminal cell (happens when the
shaper tweaks positioning, and/or when ligatures are involved).
Previously we'd render the layers in z-index order for cell N
before the layers in z-index order for cell N+1.
If N had an image that overlayed the text (nominally z-index 0.5!)
and the glyph in N+1 (z-index 0) was slightly to the left of its
border, then it could layer incorrectly over the cell to the left.
The underlying types in termwiz support 10-bit color, but in our
conversion to the data we pass to the vertex, we were forcing it
into 8-bit and then converting to float.
Simplify this by skipping the intermediate 8-bit representation
and just go directly to float.
This should give the shaper a better chance at using text
presentation in a run that mixes emoji with text and/or
uses presentation selectors.
It also exposes the presentation property to the shaper
so that it could potentially adjust its fallback strategy.
However, it doesn't do that here.
refs: https://github.com/wez/wezterm/issues/997
Make a distinction between default and selected presentation,
and account for that in the cell width.
Add a method to the cell that returns the effective presentation.
refs: https://github.com/wez/wezterm/issues/997
I'm not sure if this is needed now that we have a single draw call, but
based on the history and the nuance of different gl/driver/os quirks it
feels like a good idea to keep this option in the back pocket.
We were actually moving it during placement, and then restoring
the original placement. That could potentially lead to the
screen being scrolled, so we want to avoid that.
refs: #986
As of this commit, `kitty +kitten icat ~/Downloads/fast-parallax.gif`
(wherein the icat kitten decodes the gif into frames and sends them
to the terminal to animate) behaves equivalently in wezterm and kitty.
(There appears to be an issue with the background color/deltas in
the icat kitten in kitty-0.21.1-1.fc33.x86_64 which I have installed,
so both wezterm and kitty have a funky black background for this
particular gif).
refs: #986
These modifiers have the effect of forcing us to consider the grapheme
as being either a single cell (VS15) or two cells (VS16) in the
terminal model.
These don't affect font choice as wezterm doesn't know whether a given
font in the fallback has a textual vs. an emoji version of a given
glyph, or whether a later font in the fallback has one or the other
because we can't know until we fall back, and that has a very high
cost--we perform fallback asynchronously in another thread because
of its high cost.
Depending on the selected glyph, it may or may not render as double
wide.
refs: #997
There are some cases where we can print that status before we've
fully drained the output; it's slightly nicer to ensure that
we have an "atomic" line of its own for that, to minimize
the crappiness of the resulting output.
Since we can now mutate individual frames, we need to avoid
falsely caching across a change; switch from using (image_id, frame_idx)
to frame_hash.
refs: #986
Adds a use_image feature to termwiz that enables an optional
dep on the image crate. This in turn allows decoding of animation
formats (gif, apng) from file data, but more crucially, allows
modeling animation frames at the termwiz layer, which is a pre-req
for enabling kitty img protocol animation support.
refs: #986
This adds a simple garbage collection scheme; when adding an image,
check to see if we're over budget on the total amount of RAM used
by the image data.
If we are, remove unreferenced images (images that are not placed)
until we're below the budget.
refs: #986
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
Rather than leaving the frame un-rendered, this commit arranges
to make one last pass but with all image quad assignments skipped.
This should at least make a reasonable effort at displaying text
on the screen.
refs: https://github.com/wez/wezterm/issues/879
I noticed when running the notcurses demo that we're spending a
decent amount of time decoding png data whenever we need to
re-do the texture atlas.
Let's avoid that by allowing for ImageData at the termwiz layer
to represent both the image file format and decoded rgba8 data.
This commit is a bit muddy and also includes some stuff to try
to delete placements from the model. It's not perfect by any
means--more expensive than I want, and there's something funky
that causes a large number of images to build up during some
phases of the demo.
refs: #986
OpenGL will silently let us allocate a texture larger than the GPU can
bind to a sampler, reporting the error status out of band and leaving
the display in a perma-broken state.
This commit deliberately checks against the max texture size and raises
an error in that case.
The recovery story isn't perfect, but at least the texture remains
usable, so the user can clear the screen and still be able to see glyphs
afterwards.
refs: https://github.com/wez/wezterm/issues/879
