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
This splits rendering into 3 passes:
* background pass for z-index < 0. This is for solid background colors,
background images, and image attachments with z-index < 0.
Rendered with regular alpha blending.
* glyph pass: for glyphs at z-index==0. This is rendered with dual
source blending enabled to facilitate subpixel aa appearance.
* top layer pass for z-index >= 0 graphics. This is rendered with
regular alpha blending.
This avoids weird effects, like images with alpha shining through
the back of the window when the window itself isn't transparent.
refs: #544
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.
transparent images weren't always blending correctly, and were
instead shining through.
This might also have affected cursors.
It may also be a factor in a couple of recent reports of excessive
boldness which looked like funky over-alpha multiplication.
Let's see what people say about this.
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
