It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
As KWin indirectly uses Qt's OpenGL through QtQuick we need to ensure
to not mix OpenGL and OpenGLES. So we have to built KWin only against
OpenGL if Qt is built against OpenGL and we have to built KWin only
against GLESv2 if Qt is built against GLESv2.
This means the kwin_gles binary is no more. There is only kwin which
either links GL or GLESv2.
also work around broken fbo texture clearing on fglrx
so far supports FBO/glClear and resorts to glTexSubImage2D
if the fbo cannot be created or is (in case of fglrx)
known to break, resort to glTexImage2D loading of an
argb array of zeros
BUG: 323065
FIXED-IN: 4.11.2
REVIEW: 112526
Port from kFatal to qFatal - kFatal is still in kde4support,
but lacking debug area support arguably isn't that big a
deal since fatals can't be turned off anyway.
CCMAIL:mgraesslin@kde.org
On GLES, check for OES_texture_3D extension for color correction
Remove a block of ugly hack code that was supposedly needed to build
with OpenGL ES.
Convert the lookup texture data to uint8 on OpenGL ES before sending it
via glTexImage3D, because uint16 is not supported.
Check if the shaders have been reinitialized successfuly when trying to
activate color correction, prevent black screens when there are issues
with the shaders.
BUG: 315419
REVIEW: 111225
(cherry picked from commit 68c68ee3c2b54f968c4d8275f1e8a2e0ccc90dd7)
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
Qt 5 only supports raster which means our pixmaps are always non native,
so we don't need the Extension information any more and can drop all
special code handling for mapping a native QPixmap to an X11 pixmap.
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.
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.
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
Prevents the possiblity of using shaders modified for color correction
without valid data from KolorManager. If that happened, everthing
blacked out.
Now the color correction shaders are enabled only after successfuly
contacting KolorManager.
The issue was highlighted after ab7e228d.
BUG: 321217
it seems an animation can be triggered and the resp.
window deleted in the first event cycle (before the deleted
signal is bound) - so we add an initialization flag to ensure
the binding happens before the first animation is added
BUG: 320562
FIXED-IN: 4.11
REVIEW: 110872
Aleix Pol