* 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.
this avoids the usage of the unique_ptr PROTO::protocol before it has
been constructed incase one wants to log something inside the
constructor itself, move the logging to macros and print file:linenumber
on ERR,CRIT,WARN and classname on the rest of the levels.
XWayland does not use the regular commit(null) method to unmap, which results in buffers never being released.
release the buffers if present and un-released in the unmap() handler
ref #6584
fixes#6754
This will break if the client uses a transform that is not equal to the display, reverting to old behavior. Combining transforms is left as a todo for the future.
