Fixes#2877
As the comment in the diff states, we rely on `mmap` to zero our memory.
When we reset we are reusing previously allocated memory so we won't hit
an `mmap`. We need to zero the memory ourselves.
This is pretty slow if there is a lot of memory but in every case except
allocation failures, we expect there to be only a few pages allocated.
Fixes#2857
Some terminal modes always reset, but there are others that should be
conditional based on how the terminal's default state is configured.
Primarily from #2857 is the grapheme clustering mode (mode 2027) which
was always resetting to false but should be conditional based on the
the `grapheme-width-method` configuration.
Fixes#2848
The proper way to convert a unicode scalar in Swift is to use the
`String` initializer that takes a `UnicodeScalar` as an argument. We
were converting a number to a string before, which is incorrect.
Fixes#2781
This commit contains two separate changes but very related:
1. We update the color scheme state of the app on app start. This is
necessary so that the configuration properly reflects the conditional
state of the theme at the app level (i.e. the window headerbar).
2. We take ownership of the new config when it changes, matching macOS.
This ensures that things like our GTK headerbar update when the theme
changes but more generally whenever any config changes.
And some housekeeping:
- We remove runtime CSS setup from init. We can do it on the first tick
of `run` instead. This will probably save some CPU cycles especially
when we're just notifying a single instance to create a new window.
- I moved dbus event setup to `run` as well. We don't need to know these
events unless we're actually running the app. Similar to the above,
should save some CPU time on single instance runs.
This sets the macOS QoS class of the renderer thread. Apple
recommends[1] that all threads should have a QoS class set, and there
are many benefits[2] to that, mainly around power management moreso than
performance I'd expect.
In this commit, I start by setting the QoS class of the renderer thread.
By default, the renderer thread is set to user interactive, because it
is a UI thread after all. But under some conditions we downgrade:
- If the surface is not visible at all (i.e. another window is fully
covering it or its minimized), we set the QoS class to utility. This
is lower than the default, previous QoS and should help macOS
unschedule the workload or move it to a different core.
- If the surface is visible but not focused, we set the QoS class to
user initiated. This is lower than user interactive but higher than
default. The renderer should remain responsive but not consume as
much time as it would if it was user interactive.
I'm unable to see any noticable difference in anything from these
changes. Unfortunately it doesn't seem like Apple provides good tools to
play around with this.
We should continue to apply QoS classes to our other threads on macOS.
[1]: https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon?preferredLanguage=occl
[2]: https://blog.xoria.org/macos-tips-threading/
Fixes#2817
The test is pretty explanatory. I also renamed `end` to `count` since I
think this poor naming was the reason for the bug. In `eraseChars`, the
`count` (nee `end`) is the number of cells to erase, not the index of
the last cell to erase.
This resolves the toast showing up every time the surface config changes
which can be relatively frequent under certain circumstances such as
theme changes.
Related to #2775
This makes it so that `changeConditionalState` only does something if
the conditional state (1) has changes and (2) those changes are relevant
to the current conditional state.
By "relevant" we mean that the conditional state being changed is state
that is actually used by the configuration.
Make the foreground_color and background_color fields in the Terminal
struct optional values so that we can determine if a foreground or
background color was explicitly set with an OSC 10 or OSC 11 sequence.
This makes the logic a bit simpler to reason about (i.e.
`foreground_color` is now always "the color set by an OSC 10 sequence"
while `default_foreground_color` is always "the color set by the config
file") and also fixes an issue where an OSC 10 or OSC 11 query would not
report the correct color after a config update changed the foreground or
background color.
The `cursor_color` field was already optional, with the same semantics
(it is only non-null when explicitly set with an OSC 12) so this brings
all three of these fields into alignment.
Fixes#2791
This goes back to the previous implementation of clone that directly
cloned values rather than using replay steps, because replay steps don't
preserve conditionals on the iterator.
This works.
Another fix will be when we support some sort of conditional syntax and
the replay iterator can yield that information. We have a unit test here
so we can verify that then.
