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
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.
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.
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
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
Taking further advantage of dynamic quad allocation, we can now
remove the multiple render passes in favor of allocating the quads
and painting them from back to front.
In turn, this means that we can reduce the amount of data that we
store in the vertex, which simplifies the shaders a bit, at the
expense of making the render code in rust a bit more complex.
However, we can take advantage of stretching runs of cells with
background colors in to a single quad.
refs: #986
This was added in 365a68dfb8 to free the
orca from its cage. With the recent dynamic quad allocation changes, we
don't need a distinct 4th pass any more and can simply layer a separate
quad on top of the glyph quad.
refs: #986
This removes the pre-allocated (at resize) number of quads
and replaces it with a dynamic mechanism that tracks how many
quads are needed for a frame and then will re-allocate and
re-render when there weren't enough.
We start with 1024 quads and try to allocate in multiples
of 1024 quads.
refs: #986
This commit removes the `Quads` struct which maintained pre-defined quad
indices for each of the cells, the background image and scrollbar thumb.
In its place, we now "dynamically" hand out quads to meet the needs of
what is being rendered. There are some efficiency gains here with
things like the selection (which can now be a single stretched quad,
rather than `n` quads in width).
This isn't a fully dynamic allocation scheme, as we still allocate the
current worst case number of quads when resizing.
A following commit will adjust that so that we allocate a ballpark and
then employ a mechanism similar to OutOfTextureSpace to grow and retry a
render pass when we need more quads.
Futhermore, this dynamic approach may allow reducing the amount of stuff
we have in the Vertex and "simply" render some quads before others so
that we don't have to have so many draw() passes to build up the
complete scene.
refs: #986
This teaches termwiz to recognize and encode the APC
sequences used by the kitty image protocol.
This doesn't include support for animations, just the
transmit, placement and delete requests.
refs: #986
In the case where the cells vec is shorter than the line width,
we need to ensure that we render the inverse video background
color if that mode is in effect.
refs: #133
Also fixes an issue where only the first frame schedule would
take effect! Surprised this didn't bubble up as a bug with
animated gifs already.
refs: #133
This commit introduces a 4th draw pass for rendering sixel and
iterm images that are attached to cells.
Previously, a cell could container either text or an image from
the perspective of the renderer. If it had an image then the glyph
bitmap would be ignored in favor of the image.
However, that causes sixel behavior to diverge from other terminals
(https://github.com/wez/wezterm/issues/942) so we need to be render
both of these.
The simplest way to achieve this is to add a distinct set of texture
coordinates for the attached image and then add a draw pass to alpha
blend it over the glyph content.
The sixel/iterm image processing stage is also adjusted to preserve
the prior cell information and "simply" attach the image info to
the cell. Previously, the cell would be replaced with a blank cell
with the image attached.
The result of this is that the notcurses-demo intro section can
now render the orca "enveloped in the soft glow of glyphs" rather
than caged in a black box.
Note that there are some cases where the render turns blocky but
I suspect that that is due to some other misunderstanding between
wezterm and notcurses and that we'll root cause it as a follow up.
Looking at #900; the unconditional directory change on startup
is "bad" because it only happens on Windows.
This commit removes it and instead puts the logic into the pty
layer to match the unix behavior.
The behavior is:
* If the command specifies the cwd, use that.
* Otherwise, use the home directory
This commit causes a window-config-reloaded event to trigger
when the appearance (dark/light mode) is changed on macos.
It also arranges to propagate the window level config to newly
spawned panes and tabs, created both via the gui and via the
CLI/mux interface.
refs: https://github.com/wez/wezterm/issues/894
refs: https://github.com/wez/wezterm/issues/806
This allows window-level config overrides to apply
to panes contained within the window.
For instance, this allows setting a window-level
color scheme.
While looking at https://github.com/wez/wezterm/issues/945 I noticed
that mouse moves were being considered to be drag events even though
no mouse buttons were held down.
