This method returns true when glMapBufferRange() is likely to perform
worse than glBufferSubData() when updating an unused range in a buffer
object.
This is the case with the NVIDIA driver, where glMapBufferRange()
will force thread serialization. The driver tracks which ranges of
the buffer are in use, so calls to glBufferSubData() should not
cause a pipeline stall.
This dependency is causing build problems on a number of systems,
and it doesn't make much sense to bring in a whole library for three
one-line convenience functions.
This provides some sort of synthetic XSYNC support
for unmanaged clients and allows them to do an initial
update after mapping and before being painted (prevent
flicker)
Also it helps with Unmanaged clients performing quick
map/unmap/map cycles what also seems to induce the black
window issue on the nvidia blob.
CCBUG: 284888
BUG: 319184
FIXED-IN: 4.11
REVIEW: 111292
Instead have a synthetic motion after the effect started
and explicitly set the selected window on click/drags
BUG: 314840
BUG: 314715
FIXED-IN: 4.11
CCBUG: 314717
REVIEW: 111276
This will not provide a 100% fix, since at least KMainWindow
toolbars at some point start to behave like override_redirects
BUG: 320921
REVIEW: 111303
FIXED-IN: 4.11
Assume that the default framebuffer has the same dimensions as the screen.
By not quering the dimensions of the viewport we don't risk serialization
in drivers that use threaded dispatch.
This reverts commit 23dff966437bb664a2ffdb3f7957ef39978f5fad.
Using QVector is not a win when effects such as wobbly windows are
active, due to the realloc overhead. So revert this change for now.
using the actual delta this casewise causes false
preference for window snapping (less to move)
this restores the pre snap-to-content behavior
in that regard and delta isn't used for anything else.
BUG: 321325
FIXED-IN: 4.11
REVIEW: 111139
unmapping would do the same, but does not take
place to keep the window alive for the compositor
this breaks re-activation which takes place on
inputFocus events which won't occur since the
window got deactivated, but never lost the focus
BUG: 317484
FIXED-IN: 4.11
REVIEW: 111046
When a client becomes active on a screen with a fullscreen
window on the ActiveLayer, that window needs to be withdrawn
from the active layer explicitly as it does not get this update
with deactivation.
REVIEW: 111084
Eg. gtk+ alters the modality after mapping and
before unmapping the window.
Therfore the former implementation ahd a wrong idea
about the modality until the window was activated and
again had a wrong idea when the dialog closed, keeping
the main client dimmed.
Modality changes at runtime are uncommon but legal and can
happen anytime.
BUG: 321340
FIXED-IN: 4.11
REVIEW: 111154
similar to maximization blocking
also ensure the user can permit configure requests
for quick tiled and maximized windows
REVIEW: 111186
BUG: 321491
FIXED-IN: 4.11
fixing bug by deferring the deletion and removal of the
deleted to the next event cycle had the side effect that
this now happens in the event cycle of the compositor
restart, which was deferred to avoid precisely that...
so the test is now moved to the removal of the deleted
which got an additional flag wasClient to avoid calling
this action for each and every tooltip (and might be usable
elsewise)
BUG: 321537
FIXED-IN: 4.11
REVIEW: 111204
