Only call wl_surface_commit() after a resize when the correct size buffer is
attached to the surface. This is ensured by setting a flag on the window that prevents
all surface commits till it is cleared. The flag is cleared at next
eglSwapBuffers().
I dont actually understand if this guarantees that the
buffer size is always correct. For example, if the back buffer is
latched when wl_egl_resize_window() is called, the backbuffer will be
correct only after two swaps (I think). Or maybe the old back buffer is
discarded, I cant find any documentation about it.
All I can say is that doing it this way seems to fix the issue.
Thanks to @jadahl for his help with tracking down the root cause.
Fixes#4802
Much like toplevel configures, xdg decoration configures only take
effect once the xdg shell configure comes through. Also,
let's get rid of some double computations because we unified the code
paths.
This will let us add more stuff later. Also, it's a better spot
to put the bit field outside of the {current, pending} struct as
the bit field doesn't make any sense if it's part of the `current`
values.
This is a partial revert of e359094cff
window->wl.{width, height} and window->wl.current.{width, height}
represent different things. The former represents the actual size of the
egl surface viewport used for terminal rendering. The former represents
the size of the entire window including the CSD (client side decorations).
These numbers should be the same if CSD is disabled.
The current version of GNOME has a regression that causes the compositor
to send incorrect geometry with the next configure event if the CSD
buffers are created after a call to set_window_geometry.
So call set_window_geometry last. And shake head sadly.
We make use of the fact that wayland tells us when the window is being
resized to track actual user requested sizes as opposed to compositor
requested ones.
Now themes are loaded once per scale and stored centrally not per
window. They are not unloaded till application shutdown. Since there
is unlikely to be more than two or three scales this is not a big waste
of resources. Since cursor lifetime is tied to theme lifetime and cursors
are stored per window, destroying a theme requires destroying all
cursors win all windows referring to that theme, which is too much work.
Should hopefully fix#2810
The time is stored in a signed 64 bit integer with nanosecond accuracy. This eliminates the possibility of floating-point inaccuracies.
`monotonic_t` can currently hold values large enough to work correctly for more than 200 years into the future.
Using a typedef instead of directly using `int64_t` everywhere will also allow easily changing the datatype in the future should the need arise for more precise or bigger time values.
Kovid Goyal
pagedown
Alexander Orzechowski
Luflosi
TheDaemoness