Failed OpenGL init on Switchable Graphics falls back to Software renderer where the font weight is too light

[hgkamath]

Describe the bug

The font weight appears too light.
As a comparison, I am trying to get the font to look just the way hyper.js default font does

A clear and concise description of what the bug is.

• The font is too thin and light, readable but makes reading a little effortful.
• Selecting the Bold style is also not correct.
• I think the dpi/font-size combination is adjusted well enough that I can see that the font glyphs, spacing, style everything are the same, and line up exactly.
• not related to the theme/color (I eventually set the theme as builtin solarized light)
• not related to the choice of fonts, any selected font appears thinned out

Environment (please complete the following information):

• OS: [e.g. Linux X11, Linux Wayland, macOS, Windows]
  Windows -10 V 2020.4 OS Build 19041.329

• Version: please run wezterm -V and include its output here
  wezterm.exe -V
  wezterm 20200620-160318-e00b076c

To Reproduce

Steps to reproduce the behavior.
Please include as much information as possible that can help to reproduce and
understand the issue; some pointers and suggestions are included here in this
template. You are empowered to include more or less information than is asked
for here!

• just start wezterm with given wezter.lua configuration

Configuration

Be sure to include the relevant section(s) of your wezterm.lua configuration file.

local wezterm = require 'wezterm';

return {
  color_scheme = "Builtin Solarized Light",
  -- color_scheme = "Builtin Solarized Dark",
  
  -- The font size, measured in points
  -- default: font_size = 10.0,
  font_size = 11.0,

  -- The font family name.  The default is "Menlo" on macOS,
  -- "Consolas" on Windows and "monospace" on X11 based systems.
  -- You may wish to download and try either "JetBrains Mono" or
  -- "Fira Code" to enjoy ligatures without buying an expensive font!
  -- font = wezterm.font("Operator SSm Lig Medium"),
  -- font = wezterm.font("Source Code Pro Medium"),
  -- font = wezterm.font("Courier New"),
  -- font = wezterm.font("Fira Code"),
  font = wezterm.font("Consolas"),
  font_antialias = "Subpixel",
  font_hinting = "Full",
  font_shaper = "Harfbuzz",

  -- The DPI to assume, measured in dots-per-inch
  -- This is not automatically probed!  If you experience blurry text
  -- or notice slight differences when comparing with other terminal
  -- emulators, you may wish to tune this value!
  -- dpi = 96.0,
  dpi = 96.0,
}

Expected behavior

A clear and concise description of what you expected to happen.
Font weight needs to be thicker but not as thick as a bold font.

Screenshots

If applicable, add screenshots to help explain your problem. Screenshots are most
appropriate for rendering issues.

notice the text in wezterm (below) is thinner than hyper.js (above)

There may be a second bug in there in hyper.js, where in the foreground text of the brighter color boxes aren't switched to black, but that is not an issue for wezterm, which is getting it right. The script is Hale Tom's https://gist.githubusercontent.com/HaleTom/89ffe32783f89f403bba96bd7bcd1263/raw/

Session Recording

NA
If the issue is with the way that escape sequences are processed it can be helpful
to capture the terminal output using the wt-record
script to run wezterm and record a transcript. This requires the script utility
to be installed on your system (this is part of macOS and available in the util-linux
package on linux systems).

In the example below a file named 20180225161026.tgz is produced. Please attach that
file to this issue, or if it contains private or sensitive issue that you don't want the
public to see on GitHub, please find some other way to get that file to a project
contributor (perhaps Dropbox or email?).

$ ./wt-record
Transcript recorded in 20180225161026.tgz

You can use wt-replay 20180225161026.tgz to replay that file.

wt-record can only record the terminal output; it cannot record the input events going
in to the terminal, so if you are having an issue with input, please be sure to describe
it below!

Additional context

NA
Add any other context about the problem here.

[wez]

This is what I see when running with your config:

When I set front_end = "Software" I get this:

The software renderer isn't as good at blending as the GPU based renderer. I believe that wezterm is falling back to the software renderer on the system where you are testing this.

Could you share some details about the GPU in your system?

Please also start wezterm with info level logging enabled:

set RUST_LOG=info
wezterm.exe

That will output a lot of information, but the part I'm interested in the most is a line like this one from my system; this is printed out at the bottom:

 2020-06-29T15:09:45.344Z INFO  wezterm::frontend::gui::termwindow  > OpenGL initialized! GeForce RTX 2080 Ti/PCIe/SSE2 4.5.0 NVIDIA 451.48 is_context_loss_possible=true

I suspect that opengl isn't initializing for you, so capturing the last screen or so of logs is probably helpful.

[hgkamath]

Your guess is correct , OpenGL init had failed, Also, your software renderer output is thinned out as described.

These are the last few lines
{...}
opts: : Opt {
skip_config: false,
cmd: None,
}
2020-06-29T16:49:48.232Z INFO wezterm::mux::domain > spawned: WinChild { proc: OwnedHandle { handle: 0x260, handle_type: Unknown } }
2020-06-29T16:49:48.243Z INFO wezterm::frontend::gui::termwindow > TermWindow::new_window called with mux_window_id 0 PtySize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 432 } Dimensions { pixel_width: 640, pixel_height: 450, dpi: 96 }
2020-06-29T16:49:48.272Z ERROR wezterm::frontend::gui::termwindow > OpenGL init failed: failed to make context

... and after closing
2020-06-29T16:49:54.776Z ERROR wezterm::mux > read_pty EOF: tab_id 0
2020-06-29T16:49:54.778Z ERROR wezterm::mux > removing window 0

Hardware Info

Laptop HP Envy 17 j186nr
Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz, 2401 Mhz, 4 Core(s), 8 Logical Processor(s)
Haswell
It has a hybrid integrated Intel-HD Graphics 4600 + External Nvidia GeForce GT 740M GPU
This feature is also called Switchable-Graphics. My knowledge bout the architecture specifics is limited, but I understand it as follows. The two adaptors use a shared framebuffer, which renders to the same graphics output, in this case laptop screen/HDMI port.
The adapter selected is transparent to the applications and they are usually unaware about which graphics adapter is used. One gets better frame rates and features when using the high performance card.
As laptops have limited battery power, it is prudent to not engage the NVIDIA unless one has a specific need to.

In Windows-10, the hybrid driver system allows for running a program using either Display adaptor. When a program is run either way, the window is rendered to the final frame buffer as required by the OS/compositor.
In linux, (which I haven't tested for wezterm) the alternative display adaptors, if any, are engaged by using the environment variable "DRI_PRIME=1" .

The context menu of the Windows-Explorer allows for running an .exe executable using either display adapters

• Right click -> Run with graphics processor
• High performance NVidia processor
• Integrated graphics (default)

Selecting the NVIDIA processor does render font weight correctly.

There is a way in the NVIDIA control panel that lets set a default graphics adapter for a executable , so that one does not have to do it every time. For some stupid reason that isn't working right now. But right clicking and start manually each time does.

However, OpenGL via the Intel HD graphics should not fail.

Drivers:
NVidia 4.6.2019 25.21.14.2202
Intel 8.6.2018 20.19.15.5058

Never really had a driver issue with graphics on this laptop, and for my needs. So hesitant to fool around with the drivers. I trust HP/Microsoft to not go the beyond vendor delivered drivers and so hesitant to directly get NVidia's most advanced gaming drivers.

Running OpenGLChecker https://sourceforge.net/projects/openglchecker/
Using integrated Intel:

• GL 4.3.0 Build 20.19.15.5058
• GLSL 4.3.0 Build 20.19.15.5058
• Renderer: Intel HD Graphics 4600
• Implementer: Intel
• Total supported extensions: 199

Using NVIdia

• GL 4.6.0 NVIDIA 422.02
• GLSL 4.60 NVIDIA
• Renderer: GeForce GT 740M/PCIe/SSE2
• Implementer NVIDIA Corporation
• Total supported extensions: 344

Perhaps you're requiring some advanced OpenGL extension or a full subset, pardon me for the expression but way too much overkill for a terminal application. My knowledge here is shallow.

your terminal seems to be still best, and u seem to be attempting a mux.

• hyper.js 3.1.0: too bloated
• alacritty 0.4.3: no tabs
• gitbash/msys-mintty 2.27: good for only msys apps, needs git-bash, but tmux works
• domterm: no windows native
• temrinalpp: 0.7.2 no tabs

let me know what else I can collect.

[wez]

Thanks for the thorough info!

I think there are a couple of things to tackle around this:

• First thing I'd suggest is trying the prior release: https://github.com/wez/wezterm/releases/download/20200608-110940-3fb3a61/WezTerm-20200608-110940-3fb3a61-setup.exe
  The reason I suggest this is that I did make some adjustments to the OpenGL context setup on Windows in 8f1f1a6 and I wonder if that is responsible for OpenGL not initializing for your integrated GPU? In general, wezterm doesn't really need anything fancy from your GPU, but being able to survive a driver upgrade without terminating does require the presence of some newer extensions.
• As a little bit of an aside: I'm also curious about just how much of an impact setting wezterm to run on the nvidia GPU has on your battery life. As I mentioned, wezterm doesn't really stress the GPU (just some 2D blitting at a fixed and relatively easy framerate). If you find yourself in a position to easily evaluate that I'd welcome that feedback!
• If the prior wezterm release doesn't do the job, I'll need to do see about instrumenting the reasons behind a failure to set up OpenGL so that we have more information on what didn't work.
• Not really solving the root cause, but the symptoms: it would be nice to tune up the software renderer so that it is less visually distinct from the GPU renderer. In that case I think it would be wise to pop up a warning to let you know that software is being used as a fallback.

[hgkamath]

Your guess is again correct
Bug is introduced in the 20200620-160318 build and OpenGL init fails for intel-HD graphics in that build
I may not have caught this bug if I downloaded wezterm 2 weeks earlier. !

WezTerm-windows-20200517-122836-92c201c6
2020-06-29T20:01:06.386Z INFO wezterm::mux::domain > spawned: WinChild { proc: OwnedHandle { handle: 0x228, handle_type: Unknown } }
2020-06-29T20:01:06.396Z INFO wezterm::frontend::gui::termwindow > TermWindow::new_window called with mux_window_id 0 PtySize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 432 } Dimensions { pixel_width: 640, pixel_height: 450, dpi: 96 }
2020-06-29T20:01:06.424Z INFO wezterm::frontend::gui::renderstate > compiling a prog with version 330
2020-06-29T20:01:06.434Z INFO wezterm::frontend::gui::termwindow > OpenGL initialized! Intel(R) HD Graphics 4600 4.3.0 - Build 20.19.15.5058

WezTerm-windows-20200608-102924-d979a63
2020-06-29T20:02:05.959Z INFO wezterm::mux::domain > spawned: WinChild { proc: OwnedHandle { handle: 0x224, handle_type: Unknown } }
2020-06-29T20:02:05.971Z INFO wezterm::frontend::gui::termwindow > TermWindow::new_window called with mux_window_id 0 PtySize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 432 } Dimensions { pixel_width: 640, pixel_height: 450, dpi: 96 }
2020-06-29T20:02:05.999Z INFO wezterm::frontend::gui::renderstate > compiling a prog with version 330
2020-06-29T20:02:06.007Z INFO wezterm::frontend::gui::termwindow > OpenGL initialized! Intel(R) HD Graphics 4600 4.3.0 - Build 20.19.15.5058

WezTerm-windows-20200608-110940-3fb3a61
2020-06-29T20:02:35.874Z INFO wezterm::mux::domain > spawned: WinChild { proc: OwnedHandle { handle: 0x220, handle_type: Unknown } }
2020-06-29T20:02:35.884Z INFO wezterm::frontend::gui::termwindow > TermWindow::new_window called with mux_window_id 0 PtySize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 432 } Dimensions { pixel_width: 640, pixel_height: 450, dpi: 96 }
2020-06-29T20:02:35.916Z INFO wezterm::frontend::gui::renderstate > compiling a prog with version 330
2020-06-29T20:02:35.925Z INFO wezterm::frontend::gui::termwindow > OpenGL initialized! Intel(R) HD Graphics 4600 4.3.0 - Build 20.19.15.5058

WezTerm-windows-20200620-160318-e00b076c
2020-06-29T20:03:23.941Z INFO wezterm::mux::domain > spawned: WinChild { proc: OwnedHandle { handle: 0x228, handle_type: Unknown } }
2020-06-29T20:03:23.952Z INFO wezterm::frontend::gui::termwindow > TermWindow::new_window called with mux_window_id 0 PtySize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 432 } Dimensions { pixel_width: 640, pixel_height: 450, dpi: 96 }
2020-06-29T20:03:23.980Z ERROR wezterm::frontend::gui::termwindow > OpenGL init failed: failed to make context

If wezterm is run using NVidia graphics processor the font weight is correct as expected for all versions.
Can't capture logs for NVIDIA as it is run by right-clicking form windows-explorer
Can't capture log even by creating a windows-shortcut with command prompt redirects. There might be a way to capture logs if I write a powershell script, but not got to that.
Perhaps, a config file setting/command or a command line argument to write to log file may also be helpful

I just found wezterm and started acquainting myself with it. So I'll keep an eye out for faster than usual depletion.
Again, as you suspect, if a person is using a terminal window/batch session, then he may be already doing something of high performance and the Hardware accelerated term-window that does bit-blitting might not be the main watt-guzzler. This laptop doesn't have a long life battery anyway, hardly 45 min and I'm always on DC-power.

[hgkamath]

I used wglinfo https://github.com/gkv311/wglinfo , to check and see if GL CMDs/ARBs/EXTs used in the code diff that you pointed to are present

I think the intel-HD4600 GL-4.3 does not have two of them.

• Intel Nvidia CMD/ARB/EXT
• Y Y "WGL_ARB_create_context",
• Y Y "WGL_ARB_create_context_profile",
• Y Y "WGL_ARB_create_context_robustness",
• N Y "WGL_ARB_context_flush_control",
• Y Y "WGL_ARB_extensions_string",
• Y Y "WGL_ARB_framebuffer_sRGB",
• Y Y "WGL_ARB_multisample",
• Y Y "WGL_ARB_pixel_format",
• Y Y "WGL_ARB_pixel_format_float",
• Y Y "WGL_EXT_create_context_es2_profile",
• Y Y "WGL_EXT_extensions_string",
• N Y "WGL_EXT_framebuffer_sRGB",
• Y Y "WGL_EXT_swap_control",

wglinfo_intel.log :
20200629_wglinfo64_intelhd.log

wglinfo_nvidia.log:
20200629_wglinfo64_nvidia.log

[wez]

Thanks again for the extended information!

What I think is causing the context creation failure is that we're asking for version 4.5 and the version available to your integrated GPU from the log file you shared is:

[WGL] OpenGL version string: 4.3.0 - Build 20.19.15.5058

I did try setting the min version to 4.3 and running that locally on my nvidia based system, but while that worked for me, I'm not sure if that is "right".

Instead, I think the key insight is that we don't strictly require a minimum version and what we're missing is properly falling back to the original more basic approach if we fail to initialize the extensions, so that is what ab1e83c should achieve.

A build with that change should show up in ~15-20 minutes here: https://github.com/wez/wezterm/runs/820655363
and will show up as a "nightly" build from the downloads page within an hour or two.

[hgkamath]

The font weight is correct
The wezterm executable is from the artifact section of run 820655363
Running with the Intel HD, the log shows a fall back to basic opengl.
Running with the Nvidia GPU is also functional

>wezterm.exe --version
wezterm 20200620-160318-e00b076c-13-gab1e83c7
>wezterm.exe 
...
 2020-06-30T15:02:54.078Z INFO  wezterm::mux::domain > spawned: WinChild { proc: OwnedHandle { handle: 0x288, handle_type: Unknown } }
 2020-06-30T15:02:54.095Z INFO  wezterm::frontend::gui::termwindow > TermWindow::new_window called with mux_window_id 0 PtySize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 432 } Dimensions { pixel_width: 640, pixel_height: 450, dpi: 96 }
 2020-06-30T15:02:54.128Z ERROR window::os::windows::wgl           > failed to created extended OpenGL context (CreateContextAttribsARB failed), fall back to basic
 2020-06-30T15:02:54.152Z INFO  wezterm::frontend::gui::renderstate > compiling a prog with version 330
 2020-06-30T15:02:54.164Z INFO  wezterm::frontend::gui::termwindow  > OpenGL initialized! Intel(R) HD Graphics 4600 4.3.0 - Build 20.19.15.5058 is_context_loss_possible=false
...

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.