Plasma and KWin Integration

[Zack Rusin]

On Tuesday 10 February 2009 22:13:00 Zack Rusin wrote:
> Well, whoever is saying that is wrong. Using the raster engine is the
> opposite of what Plasma wants. The person who wrote a blog entry about how
> to make it the default in Qt has been doing a huge disservice to the whole
> community.

Actually, instead of assuming that everyone can read my mind, let me explain 
why that is.

Plasma is a long term project, equivalent to a cross country trip. And on that 
trip we have two choices the first one is a car without any gas, the other one 
is walking. Using the raster engine is equivalent of walking. Using the car, 
which in this metaphor is your graphics card is a obviously the right choice. 
Assuming we get the gas, which in this metaphor equals improving the driver 
situation all over the our stack.

So if we want to have a well working graphical stack, we need to actually put 
some work into it. 

The problem is that whenever someone says "GL doesn't work" they always point 
to a huge application and one has to dig through the application code and then 
Qt code to figure out what's not working. And the reality is that no one who 
works on drivers has simply the time to do that. So while we fix tons of bugs 
daily, likely a small percentage of them affects Qt and KDE.

What we need is a set of small applications that test specific features in Qt.

Like drawing a linear gradient, drawing a radial gradient, stroking a glyph, 
filling a glyph (glyphs because they tend to be fairly complicated paths) and 
so on.  
The GL code that is used by Qt OpenGL QPaintEngine to implement them needs to 
be extracted from Qt and stuffed into small programs along the lines of what we 
have in:
http://cgit.freedesktop.org/mesa/mesa/tree/progs/trivial

If we had those, not only would be able to fix very quickly the problems, I'd 
probably even add them to Mesa git repo directly to make sure they don't 
regress. So if we really care about graphics then lets try to make this 
happen.

z