This is similar in spirit to the work in 4d71a7913a
but for Windows.
This commit adds ANGLE binaries built from
07ea804e62
to the repo. The build and packaging will copy those into the same
directory as wezterm.exe so that they can be resolved at runtime.
By default, `prefer_egl = true`, which will cause the window
crate to first try to load an EGL implementation. If that fails,
or if `prefer_egl = false`, then the window crate will perform
the usual WGL initialization.
The practical effect of this change is that Direct3D11 is used for the
underlying render, which avoids problematic OpenGL drivers and means
that the process can survive graphics drivers being updated.
It may also increase the chances that the GPU will really be used
in an RDP session rather than the pessimised use of the software
renderer.
The one downside that I've noticed is that the resize behavior feels a
little janky in comparison to WGL (frames can render with mismatched
surface/window sizes which makes the window contents feel like they're
zooming/rippling slightly as the window is live resized). I think this
is specific to the ANGLE D3D implementation as EGL on other platforms
feels more solid.
I'm a little on the fence about making this the default; I think
it makes sense to prefer something that won't quit unexpectedly
while a software update is in progress, so that's a strong plus
in favor of EGL as the default, but I'm not sure how much the
resize wobble is going to set people off.
If you prefer WGL and are fine with the risk of a drive update
killing wezterm, then you can set this in your config:
```lua
return {
prefer_egl = false,
}
```
refs: https://github.com/wez/wezterm/issues/265
closes: https://github.com/wez/wezterm/issues/156
The nightly builds seem to often trip over each other when
uploading the source tarball from ubuntu20.
Restrict it to being built only on the appimage build (ubuntu16).
The mac builds started to fail with a crate resolution issue that I
can't reproduce locally shortly after I updated the cache action. Let's
tweak the cache key to see if that clears things up.
This is a bit of a switch-up, see this comment for more background:
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
This commit:
* Adds a pre-compiled mesa3d opengl32.dll replacement
* The mesa dll is deployed to `<appdir>/mesa/opengl32.dll` which by
default is ignored.
* When the frontend is set to `Software` then the `mesa` directory
is added to the dll search path, causing the llvmpipe renderer
to be enabled.
* The old software renderer implementation is available using the
`OldSoftware` frontend name
I'm not a huge fan of the subdirectory for the opengl32.dll, but
I couldn't get it to work under a different dll name; the code
thought that everything was initialized, but the window just rendered
a white rectangle.
Rather than scanning directories and reading in ~230 files on startup,
do the scan at build time so that we're parsing from memory rather
than local storage.
This should shave a bit of time off the startup, although I
haven't measured this, and I've only run this on a remote
linux system thus far.
refs: https://github.com/wez/wezterm/issues/264
This is untested beyond eyeballing the locally generated file.
Will need to make a couple of tags to test this for sure.
refs: https://github.com/wez/wezterm/issues/209
When installed by the installer, we add registry entries to configure
directory context entries in explorer.exe that enable "Open WezTerm
here" to function.
This works by running your default program with the current working
directory set to the one specified.
I plan to only enable this when installed by the installer so that
these can be deleted/updated by the installer later on.
If you want wezterm to run a different program by default, then
you can change the default_prog config in the wezterm configuration;
I don't plan on adding lot of context menu entries for this.
Note that attempting to open in the `C:\` root doesn't always seem
to work for me. I haven't had a chance to understand what's going
on there.
refs: https://github.com/wez/wezterm/issues/155
I've been meaning to do this for a while: the intended purpose
is to use this to filter ansi escape sequences out of the prompt
in the shell pre-command hook.
tweak some container names
fixup container names and regenerate the config
Ensure that curl is installed
the rust toolchain stuff wants curl
run apt update before apt install
centralize updating apt, and install sudo
revise get-deps script for slimmer debian images
more container related tweaks
get-deps: Don't require lsb-release on debianish systems
more get-deps improvements
Explicitly ask GH actions to recursively checkout the repo
Explicitly install git
fetch tags and tweak git build for debian systems
moar adjustments
remove deb8 (its wayland is too old), fixup debian publish
Ensure git build deps are installed always, tidy up sudo usage
This commit allows loading the console functions from `conpty.dll`
instead of `kernel32.dll` which means that we can update and
track newer features than have been deployed to Windows.
In practical terms this means that we can now unlock mouse input
reporting in eg: VIM running under WSL.
refs: https://github.com/microsoft/terminal/issues/376
We're jumping the gun on this issue, which is tracking making
a proper supportable way to deploy this sort of update:
refs: https://github.com/microsoft/terminal/issues/1130
For now it seems easier just for us to bundle our own copy of
these bits.
This includes a speculative change to include those in our
Windows downloads also.
The binaries were built from
4f8acb4b9f
