On NVIDIA it is possible that the actual rendering gets delayed to
after the deletion of the pixmap during the end of fullscreen effects.
This was causing freezes. By using glFlush before deleting the pixmaps
we can ensure that the pixmap is not needed anymore after the pixmaps
are deleted.
BUG: 261323
FIXED-IN: 4.6.3
The Shadow is clearly an aspect of the compositor. Therefore the
Shadow has to be owned and controlled by the Scene::Window.
Nevertheless Toplevel needs to know about the Shadow cause of reading
the property.
For a complete documentation of new functionality refer to:
http://community.kde.org/KWin/Shadow
The current implementation includes a new Shadow class and Toplevel
holds a pointer to an instance of this class. The Shadow class reads
the data from the X11 Property. There is one extended class located
in SceneOpenGL to render the shadow.
Compositor is adjusted to include the shadow region into the painting
passes.
Implementation for XRender still missing and Shadow needs to respond
to size changes of the Toplevel to update cached shadow region and
WindowQuads.
Second part of cleaning up the lib directory: the effects library
now lives in libkwineffects/ directory.
For existing effects nothing changes as the install path is unchanged.
The change obsoletes the lib/ directory.
As glplatform.h has not yet been exported I dared to export it and
adjust the places where it is used.
CCMAIL: kwin@kde.org
Our primary target is Texture From Pixmap and it is supported
by all important drivers nowadays. If a driver is not able to
support TFP using OpenGL at all is probably no good idea and
XRender is more suited.
When rendering opaque (RGB-only) windows the alpha ends up to be 0
with blending disabled. This breaks subsequent rendering steps which
require blenden (e.g. Lanczos). Therefore a uniform is used to ensure
that the alpha channel is set to 1.
The vertex buffer implementation uses the shader manager to decide
whether core painting should be used or not. Shader manager is only
used by shaders using vertex attributes instead of gl_Vertex etc.
A color can be specified to render the geometry of the VBO.
For legacy painting glColor is used, for shader a uniform is set.
In order to allow rendering without texcoords, it is possible to pass
a null pointer as texcoords.
Shader added to scene which just renders a colored geometry without texturing.
Adds a shader to render an untransformed scene. renderGLGeometry is not used any more and replaced by generated triangles stored in a GLVertexBuffer.
The GLVertexBuffer has a new attribute to decide whether a core profile compatible rendering has to be performed.
Currently windows and EffectFrames can make use of the new shader.
The shader contains a debug mode which colours all rendered fragments in green. It is currently enabled in scene_opengl.
Rendering transformed geometries (without shader) is currently broken.
differecens to patch atteched to 258971:
- removed debug statements
- fixed indention...
- NON vsync strategy does not rely on the estimation, but on the time passed since the last repaint trigger, allowing a precise framerate
CCBUG: 258971
svn path=/trunk/KDE/kdebase/workspace/; revision=1210445
this should improve v'syncing, maybe v'synced "smoothness"
remaining and exposed issue are "dirty textures" w/o damage events (see the requst description)
can be diminished by increasing MaxFPS above the fastest update (or shadowed below the slowest one)
CCBUG: 258971
svn path=/trunk/KDE/kdebase/workspace/; revision=1207577
The GLX implementation in the X server appears to have a hardcoded limit
to how many pixmaps can be bound to textures simultaneously when using
indirect rendering, which we can end up exceeding with the changes
introduced in r1182198.
BUG: 256359
FIXED-IN: 4.5.5
svn path=/trunk/KDE/kdebase/workspace/; revision=1203578
This worksaround a problem with the nouveau driver causing
the text frames to be incorrectly rendered. We need to keep
the QPixmap around as long as we have a texture created from
that texture.
This applies for the text and the unstyled effect frame. For
the frames generated from Plasma's FrameSvgs it is not required.
Addresses freedesktop.org bug 30286
svn path=/trunk/KDE/kdebase/workspace/; revision=1184458
Prefer the GL_TEXTURE_2D target if the framebuffer configuration indicates
that it's supported.
This fixes a performance problem with the r600g driver.
freedesktop bug 30483.
svn path=/trunk/KDE/kdebase/workspace/; revision=1183978
