I have KWin X11 and the window does not receive expose event
when the window is exposed. This seems to be the reason why
the video freezes after the window gets minimized.
We can use the transparent area to restrict the client
size and use that remaining extra size for resizing.
This size needs to be adjusted with regard to the dpi.
Note that on Windows 10 and Windows 7, this brings
borders.
`QWindow::show()` does not necessarily care about the state
of the window, but rather uses the default behavior for the
platform.
Since we adjust the window geometry and states before the
window is shown (which is the expected behavior, as otherwise
the window would get adjusted immediately after shown), using
`QWindow::show()` potentially overrides the window states
nullifying the behavior of the interface starting maximized.
CompositorX11, unlike others, requires explicit code to
adjust backdrop blur. When the effect gets activated at
a later time after initialization, it currently does not
have code to do the required adjustment.
This is a regression since b1e11641. I did not notice
it because I was using extended frame with CSD, where
this regression is masked.
don't let render dummy window eat away mouse events and let it correctly
propagate to the desired location
fixes#27240
fixes erratic CSD resize with x11 compositor
afterRendering is emitted before the frame is presented, on
afterRendering signal we update the x11 compositor but the frame is not
presented yet, so the compositor paints the old frame instead of new one
fixes#27188
Note that in some cases they have been changed to forward declarations, and
in some they have been moved, for instance inclusion of `<QUrl>` was moved
from `qt.hpp` to where it was needed.
widget would normally require WindowTransparentForInput, without this we end up
with an invisible area within our window that grabs our mouse events. But using
this this causes rendering issues with some VoutDisplay (xcb_render for
instance) instead, we manually, set a null intput region afterwards (see
setTransparentForMouseEvent)
The composition works as follow:
* Both the interface and the video are rendered in an offscreen window (using
X11 composite extension)
* We register to damage event (x11 damage extension) to get notified when the
content of the offscreen video window change. When we receive a damage event
we ask the rendering part of the composition to refresh
* The interface is rendered in the offscreen surface using a RenderControl, when
the interface do render, the composition is asked to refresh
* A dedicated thread is spawned to do the rendering, upon a refresh event it
will take the pictures from the offscreen surface and blend them into the
actual window using X11 render extension. Using a separated thread from Qt
ensure that the rendering of the video will not be stalled if Qt thread is
busy.
* The damage events are listened on a separate X11 connection and on a separate
thread than Qt main thread (here the rendering thread). This allows to receive
theses events independently from Qt (in case the Qt thread is stalled). Note
that it is not possible to peek in qt X11 event queue from a non gui thread as
the QX11Info::peekEventQueue is no longer thread safe since 5.12.
fixes: #25627, #22155
Fatih Uzunoglu
Pierre Lamot
Prince Gupta
Lyndon Brown