This ensures a couple of things:
- avoid pointlessly binding and unbinding the texture
- if the image format needs to be changed, it will be done only once
The scene renderer doesn't use external_only formats as a single EGLImage, but only does
YUV conversion for some specific formats, so the test import should match that.
Applications that use QtWidgets can have a lot of rectangles in the
damage region. For example, when you navigate between directories in
Dolphin, each individual file or folder item will be added to the
damage region rather than the container view where they are.
On the other hand, issuing multiple glTexSubImage2D() function calls
is not great because it means stalling the cpu until the texture upload
completes.
This change attempts to improve that by simplifying the input damage.
If the input damage isn't complex, use it as is; otherwise use its
bounding rect.
The gains are not impressive. On my machine, I see fewer 5ms texture
upload time spikes when navigating in Dolphin, now I can observe 4ms
spikes instead. Still, I believe the change is reasonable enough.
If the graphics buffer view is null, GraphicsBufferView::image() will
point to a valid memory location but the QImage at that address is going
to be null.
It's fine to be conservative about what kind of buffers we support, but
failing silently only makes it hard on such cases.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
linux-drm-syncobj-v1 allows drivers and apps to synchronize KWin's buffer access
to their rendering, and synchronize their rendering to KWin's buffer release. This
fixes severe glitches with the proprietary NVidia driver and allows for some
performance improvements with Mesa too.
If two items display image data, the item renderer needs to special case
each item. It's not an extensible design, and my long term goal is to
introduce a separate tree specifically to solve this problem and also
help with computing the repaint damage automatically, instead of issuing
scheduleRepaint()s manually.
The first step is to refactor the item renderer so it merely takes the
input data and renders it. At the moment, it's not exactly the case
because surface textures are updated while painting the items, which
inherently requires special casing. This change moves surface texture
update code to the surface item so it's easier to refactor rendering code
in the item renderer.
While KWin may not have information about the formats, that doesn't mean KWin
should filter them out - EGL can still import them, so allow clients to use them
The environment variable is primarily meant as a workaround for displays
and drivers that misbehave when more than 8 bits per color is used. To simplify
the code, this commit makes the environment variable only control the bpc
used for displays, instead of also controlling which buffer formats get
used.
Apparently, libepoxy requires a current EGL display in order to resolve
EGL functions. This is unexpected as most of the EGL functions require no
current opengl context.
This change makes kwin bypass libepoxy for problematic cases.
BUG: 470980
If there's a supported mechanism to handle the format, announce them as
supported.
If there are modifiers supported by the graphics card (even though as
external only), offer them as well.
libkwineffects was introduced when kwin used to be an executable. It
provided an api to implement effects and shielded from the technical
quirks in kwin.
Over the time, kwin internals had been split and abstractions were
refactored so they can be consumed in scripts or plugins. Besides that,
new ways to implement extensions have been introduced, which use
kwin's internal abstractions.
On the other hand, effects continue using libkwineffects specific apis.
This has a few issues: qtquick effects use both apis and it bites us,
duplicating same apis.
The best solution so far is to merge libkwineffects with libkwin, and
replace libkwineffects abstractions with libkwin abstractions, e.g.
EffectScreen -> Output, etc. This change takes care of adjusting libs.
Obviously, the main disadvantage of doing so is that binary effects
have to be recompiled every time new libkwin is released. But it's
already the case with libkwineffects too.
In order to destroy resources from a context on the secondary GPU, that
context needs to be current. We also want to destroy the context once it's
no longer used, if the GPU is unplugged etc, so this commit uses shared
and weak pointers to manage the lifetime of the contexts
Config loading is split in two groups: loading compositing config and
loading the rest. They are loaded separately at different times. Some
options are loaded in the Options constructor, some are loaded when compositing
starts, some are loaded when the Workspace is created. It's not easy to
keep track of what loads what and when.
This change simplifies option handling by loading all options in bulk
and decouples Options from OutputBackend and GLPlatform to ensure that
it can safely load options before kwin is fully operational.
Instead, creating contexts that miss these features should fail directly,
making KWin fall back to software rendering.
While this commit also drops workarounds for broken drivers that do software
emulation for features we need, such workarounds belong into these drivers and
the user can still manually turn off compositing if needed.
This commit also drops most of the code around checks for direct rendering. If
direct rendering isn't supported, creating the OpenGL context will now simply fail,
achieving the same effect
At the moment, graphics buffers coming from wayland and internal windows
use different code paths to update textures. However, they don't have
to.
If the internal windows are ported to GraphicsBuffer, it will be
possible to unify SurfacePixmapInternal and SurfacePixmapWayland to make
pixmap logic a bit simpler.
With simpledrm, only linear modifiers are supported, but with llvmpipe, only
implicit modifiers are supported. As it's still possible to allocate linear
buffers without modififer support by using GBM_BO_USE_LINEAR, this commit fixes
that problem by adding linear modififers to the supported list.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
