* xwayland: add inline safe closing of fds and fix LOCK_FILE_MODE permissions
* xwayland: auto recreate xwayland instance if it crashes
* xwayland: delay auto-restart until later
When an asset is missing, instead of a black screen, render an obnoxious, yet standard, missing texture.
Additionally, warn the user assets failed to load.
Shoutout to Arch for having their assets broken for months. Fix your shit. I am tired of it, and it's negatively impacting users.
* snap: add option `border_overlap` and other improvements
I really liked the way borders used to overlap when snapping and how
only the window's main surface would snap to the monitor, so I would
like to bring that behavior back, but in the form of a config option.
Other improvements include:
- reduced the number of snap functions from 4 down to 2, and only
one ever gets called at any given time.
- border size should not be added to gap size. It seemed like the
right thing to do at the time, but it makes snapping feel way
stronger than it actually should.
- all const variables have been given the all-caps naming convention.
- to avoid excessive casting, border size is declared as a double.
- to avoid excessive x + w, y + h calculations. I'm using a struct
called Range and working only with start and end values until the
very end of the function.
- check for both monitor snapping as well as reserved monitor space
snapping in a relatively efficient way.
* snap: always border-align for corners and reserved monitor space
We probably don't want to treat reserved monitor space as if it were just
a smaller monitor. Instead, it should be treated more like a borderless
window, which means our window's border should never encroach upon it.
* compositor: reduce amount of window box copies
mousemoveunified can call this very frequently, the cbox copying
actually shows up as an impact in such cases, move it down in the scope
and only do it when necessery.
* core: constify and reference frequent calls
profiling shows these as frequent called functions try to reduce the
amount of copies with references and const the variables.
* pointermgr: remove not used local copy, const ref
remove unneded local copies and const ref cursorsize.
* inputmgr: reduce amount of calls to vectortowindow
the amount of calls to g_pCompositor->vectorToWindowUnified fast ramps
up in cpu usage with enough windows existing and moving the mouse, move
the PWINDOWIDEAL up and reuse it if its already the same.
* protocol: compositor remove unused local copy
remove unused local copy of accumulateCurrentBufferDamage and const
previousBuffer.
* renderer: reduce scope of variables and refactor
move a few variables down in their scopes to reduce the amount of calls
and copies when not needed, also add one more for loop in
renderWorkspaceWindows and store the windows in a vector with
weakpointers that should be rendered, this adds a loop but reduces the
amount of repeated calls to shouldRenderWindow and also makes the rest
of the loops go over way smaller vector when many windows exist.
#### Describe your PR, what does it fix/add?
Fix lag spikes when pressing more than 6 keys at the same time.
#### Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
Debugging process:
<details>
This is triggered by typing some applications, like CopyQ or XWayland.
Typing in Firefox doesn't lead to lag, however it itself does lag
handling these events.
Profiling CopyQ shows that paths leading to
`QtWaylandClient::QWaylandInputDevice::Keyboard::keyboard` take over
80% of processing time of an otherwise idle program.
Looking at output of 'wev' even when it's not focused shows same events
received over and over again.
```
[14: wl_keyboard] repeat_info: rate: 25 keys/sec; delay: 300 ms
[14: wl_keyboard] keymap: format: 1 (xkb v1), size: 64754
```
Looking at what passes through CInputManager::onKeyboardKey() ->
CSeatManager::setKeyboard() shows Hyprland 'switching' between endpoints
of the same keyboard, one of them being named like the other but with
'-1' suffix.
</details>
Tested changing layouts in Fcitx5 and with following config.
```
input:kb_layout = us,cz
input:kb_variant = ,qwerty
input:kb_options = grp:alt_shift_toggle
```
Also tested changing 'input:repeat_delay' while running.
Curiously, now these events appear in the output of 'wev' only once.
Changing layouts still seems to work fine though.
#### Is it ready for merging, or does it need work?
Ready for merging.
* deco: reduce local temporars and function calls
profiling shows this is a high used function, reduce the amount of
function calls and local temporar copies and also check if we even need
to add extents at all in the loop.
* popup: optimize bfhelper in popups
pass nodes as const reference and reserve the size of the children node
vector help reduce the reallocations.
* procotol: make compositor bfhelper use const ref
use const ref for nodes and reserve second nodes vector size to reduce
amount of reallocation needed.
* window: inline and const getWindowMainSurfaceBox
getWindowMainSurfaceBox gets called a lot of times from deep down from
mousemoveunified, profiling mousemoveunified it spends quite a lot of
cpu time in here, let the compiler optimize the call to
getWindowMainSurfaceBox by inlining and making it const. reducing the
overhead.
* inputmgr: return early and use std::any_of
return early in mousemoveunified to reduce the amount of unnecessery
calls to various pointers when not needed, also make isconstrained use
std::any_of instead of for loop to use the STL optimized paths with
hopes and dreams marginally faster.
* decoration: return early, reduce temporar copy
return earlier and reduce the temp copies by using one .lock instead of
two
to safely use wl_container_of with a class the class has to be no
virtual functions, no inheritance, and uniform access control (e.g all
public)
work around this by putting this into a destroywrapper struct.
* add snapping to floating windows
Works for both moving and resizing of windows.
It comes with 3 options:
`general:snap:enabled` - whether it's enabled, off by default
`general:snap:window_gap` - minimum gap in pixels between windows before
snapping. Setting to 0 effectively turns off this method of snapping.
`general:snap:monitor_gap` - minimum gap in pixels between window and
monitor edges before snapping. Again, setting it to 0 effectively turns
it off.
* snap: add more ignore criteria and change if clause into a guard
* snap: refactor code
* snap: new refactoring approach and account for border size
* snap: do corner snapping after all edge snapping is done
The approach of performing corner snaps after each individual edge snap
results in far fewer scenarios where snapping can occur.
After trying it out for a while, I found that I prefer an approach
that's more prone to snapping.
* snap: combine snapWindows and snapMonitor into a single function
* snap: add forced aspect ratio functionality
* snap: avoid directly referring to border_size config value
* snap: address vaxerski feedback
- add new line between functions
- use std::function typedef for SnapFn and make snap functions static
- avoid uninitialized variable declarations.
- change ignore condition m_bIsX11 to isX11OverrideRedirect()
- use braces for CBox and Vector2D declarations.
- add SNAP_INVALID to eSnapEdge enum
- use bitshift notation for eSnapEdge and eRectCorner
- make performSnap a non-member function.
* snap: add corner-snapping to forced aspect ratio mode
* layout: enable group rules for new floating windows
* fix comment
* do not apply group rules to a new floating window if it shouldBeFloated.
fixes child windows
* comment
If `default_split_ratio` is greater than 1.0, `split_bias` will give the
bigger half to a specific window:
0 - positional (default)
1 - current window
2 - opening window
Only the fork provides a .pc file, so there's no risk of linking the wrong
lib version. If pkg-config can't find it (most cases), fall back to using
the subproject through the wrap file.
ref https://github.com/hyprwm/xdg-desktop-portal-hyprland/issues/251
if the XDG_CURRENT_DESKTOP is externally managed (e.g. DE, DM, etc) Hyprland will not overwrite it. In those cases, if that's undesired, portals and other apps depending on it might break.
