Another week is gone and my KWin-GLES branch got further polishing. All developing on the OpenGL ES code is nowadays happening on my notebook using KWin-GLES. So it is already so useable that I can develop on it without real problems. Most of the effects are already ported and can be used. Today I added the first 3D effects, that is CoverSwitch and FlipSwitch and a (locally) half finished Cube Desktop Switch animation. Quite nice to see the new code working as expected 😉 Only eleven effects are not yet ported, but these include some effects which won’t be ported, such as FPS, Sharpen or Shadow effect.
KWin has now three default shipped shaders, which can be used by both effects and the compositing scene. There is one shader to render simple 2D textured graphics. It’s a straight forward simple shader for the normal tasks. A second, more generic shader is available for all kind of transformations: translating, scaling and rotating of the complete screen or windows. Last but not least there is one shader to render simple colored geometries. I noticed I need that one, when I started to port the ShowPaint effect (one of the most important ones).
Going on ES means that everything has to be rendered with shaders and geometries have to be passed using a vertex buffer object (VBO). For 4.6 I added an abstraction to VBOs which is only used by the EffectFrames (overlays in e.g. PresentWindows effect). Now all effects and the scene rendering has to use those VBOs. The way KWin works it’s mostly streamed data, so there is one VBO which can be shared by all effects.
The old code looked like that:
glPushAttrib( GL_CURRENT_BIT | GL_ENABLE_BIT ); glEnable( GL_BLEND ); glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ); float alpha = 0.2; const QColor& color = colors[ color_index ]; glColor4f( color.red() / 255., color.green() / 255., color.blue() / 255., alpha ); glBegin( GL_QUADS ); foreach( const QRect &r, painted.rects()) { glVertex2i( r.x(), r.y()); glVertex2i( r.x() + r.width(), r.y()); glVertex2i( r.x() + r.width(), r.y() + r.height()); glVertex2i( r.x(), r.y() + r.height()); } glEnd(); glPopAttrib();
We see here quite some deprecated stuff like glBegin/glEnd, this needs to be replaced by a VBO. Each quad has to become two triangles and of course it’s not allowed to set the color (that has to be done in a shader). Last but not least the attribute stack is not available which means we need to explicitly disable blending. The new code looks like that:
#ifndef KWIN_HAVE_OPENGLES glPushAttrib( GL_CURRENT_BIT | GL_ENABLE_BIT ); #endif GLVertexBuffer *vbo = GLVertexBuffer::streamingBuffer(); vbo->reset(); vbo->setUseColor(true); if (ShaderManager::instance()->isValid()) { ShaderManager::instance()->pushShader(ShaderManager::ColorShader); vbo->setUseShader(true); } glEnable( GL_BLEND ); glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ); QColor color = colors[ color_index ]; color.setAlphaF(0.2); vbo->setColor(color); QVector<float> verts; verts.reserve(painted.rects().count()*12); foreach (const QRect &r, painted.rects()) { verts << r.x() + r.width() << r.y(); verts << r.x() << r.y(); verts << r.x() << r.y() + r.height(); verts << r.x() << r.y() + r.height(); verts << r.x() + r.width() << r.y() + r.height(); verts << r.x() + r.width() << r.y(); } vbo->setData(verts.size()/2, 2, verts.data(), NULL); vbo->render(GL_TRIANGLES); if (ShaderManager::instance()->isValid()) { ShaderManager::instance()->popShader(); } glDisable( GL_BLEND ); #ifndef KWIN_HAVE_OPENGLES glPopAttrib(); #endif
Unfortunately we currently need to ifdef the attribute stack. I am planning to go through the complete KWin code and remove all of those later on. The VBO for streaming is used to set the vertices. Also the color is attached to the VBO. When rendering is performed the VBO either uses the legacy glColor or sets a uniform of a bound shader. The new ShaderManager is used to bind the shader for colored geometries. This manager takes care of restoring a previous bound shader when unbinding the shader. As we can see the shader is only bound if it is valid. So this code works for both the legacy rendering as well as the modern shader based rendering. The effect itself does not even need to care about it. All the differences for passing the geometries, setting the color, etc. are abstracted away in the VBO. With these changes porting an effect is mostly straightforward.
Now with most effects and functionality ported I can start looking at the finishing touch. I split several methods in a glx and egl specific variant and noticed later on that the differences are rather small. Those have to be merged again and I have to ensure that everything is still working when not using GLES. I am still aiming for importing everything into master as soon as kdebase-workspace migrates to git. Maybe I will give it one week or two to settle down before merging into master, but I’m quite confident that we will see this in master very soon.
=-=-=-=-=
Powered by Blogilo
You are amazing. 🙂
I’ve tested yesterday your work against a beta2 (4.5.85), let me say this is really a wonderful job. The most useful plugins are there and working.
two questions:
1) why not “Show FPS”?
2) it seem a bit slower than my kde 4.5.4, I’m unsure if the difference is between stable and beta or GL and glES. What do you think the performances on desktops will be (in comparison with GL & possibly with kde-4.5)?
Configuration here is “ATI Radeon HD 5400 Series” EvergreenC id:68F9; linux-2.6.37-rc5, libdrm and mesa from git. The only proprietary drivers free configuration stable enough to do daily work.
to 1): because it’s showing incorrect data and is in general useless and difficult to port
to 2): my experience is that it is faster with glES than normal GL. But this is very much driver specific.
And why won’t the Sharpen and Shadow (and others?) effects be ported?
For each effect there is a reason. Sharpen is just useless. It has a bad, unperformant design and for example the NVIDIA driver provides the same capabilities inside. Shadow is too broken to even think about porting. It would be easier to reimplement it from scratch and there is an alternative effect.
In general I would ask you to just trust the people who work on it and decide why an effect is dropped.
Hehe, I trust you! I was only curious.
I dont know if this is related, but ive been playing with rgba and the qtcurve theme. it already does amazing stuff (even has support for blending), BUT the main problem for enabling rgba by default remains. the XEMBED problem (i believe thats the name), when you activate rgba with kwin, the video windows become translucent and useless.
I was told this is a problem with qt and xembed, but no one never looked at a way to solve this. do you know if this will ever be taken care, so we can finally have rgba real translucency effects (we are so close and yet so far).
anyway, great work.
ps, could you write a post on how to use scripts in kwin 4.6? i wanted to play around a bit with kwin scripting, but i cant find any good examples/docs.
Will be solved with Wayland
Wow, you rock. Glad things are shaping up and getting simpler- you’re building a good foundation for some solid mobile performance here. Keep kickin’ ass with the code, the users are proud of what you’re doing. 😀