[Kde-games-devel] Fwd: Re: SVG Rendering speed

[Luciano Montanaro]

Il Sunday 30 September 2007 20:42:53 Aaron J. Seigo ha scritto:
> On Saturday 29 September 2007, Ian Wadham wrote:
> > Andreas and Aaron's responses to these problems seem a bit
> > Microsoftish, if you do not mind me saying so, i.e. get the next version
> > of software, buy more hardware.  I am on my third Linux/KDE box
>
> Ian, this really is a problem with x.org. the X11 protocol is ok, but the
> x.org implementation of various things are sorely lacking in many places;
> e.g. XRender is virtually hardware un-acceleratable in modern terms; this
> is a "broken by design" sort of thing. there are many such areas in x.org.

To be fair to xorg people, they seem to be addressing the issues. New drivers 
are better at XRender, the Intel driver is good, and even my Radeon 9250 can 
accelerate the effects well enough with the latest update. We have an issue 
with non-free drivers, where little can be done.

But enabling composite for KWin reveals graphic glitches (see B2 window 
decoration with and without composite enabled) which may be due to render 
implementation bugs or Qt bugs, I don't know.

So, I'm not sure we can realistically expect people will have render and 
composite enabled for KDE4 release. In another year, maybe, it looks like new 
acceleration architectures are growing like mushrooms...

>
> the lack of composition based window management has been another long
> standing one that is finally getting resolved.
>
> i don't see how saying "this sotware written by someone else is broken by
> design" is Microsoftish in the least. expose event annoyances have been
> there since KDE1 in various forms. the issue is that unless the content of
> the window itself changes, then no repaints should be requested from the
> window; exposes should be handled in the windowing system by a simple
> blitting of the already-rendered pixmap in memory.
>
> then you can get silky smooth rendering.
>
> there are, of course, some times we can fix things. e.g. an issue has been
> Qt's use of child windows for widgets. many (most?) of the X people said
> (and some probably continue to suggest) that this is the Right Way.
> Trolltech recently changed this and now only has one native window (the
> toplevel widget) unless otherwise requested. this results in some pretty
> amazing fluidity improvements, particularly on resize events (since we can
> now properly synchronize/minimize the painting).
>
> the other issues you raise (SVG parsing efficiency, QPainter speed, etc)
> are independant issues. which is why i specifically replied to the part
> about windows repainting in your email. you even noted it could be an issue
> rooted in X; i was simply affirming that that is likely the case for that
> particular set of visual artifacts =)

I'm not sure the parser is too bad; I tried to use a QPicture as the paint 
device and to time drawing that or using SVGrender, and the results were 
comparable. So it's actually drawing complex SVG that is not very quick. 
There should be room for improvement, but I don't think it's a serious issue 
for now.

Maybe we could try to keep the main widget hidden until graphics has been 
loaded? 

Luciano