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

[Ian Wadham]

> On Saturday 29 September 2007, Ian Wadham wrote:
I was writing about a large white rectangle hanging about in front of
the central widget in KGoldrunner, after the initial dialog box closes.
I am running with *no* graphics acceleration and no KDE 4 desktop.

On Mon, 1 Oct 2007 04:42 am, Aaron J. Seigo wrote:
> 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.
>
> the lack of composition based window management has been another long
> standing one that is finally getting resolved.
>
> 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.
>
I have been investigating this problem quite a lot lately.  What mystifies
me completely is that I can click and hold on the dialog box's title bar
and then drag the box around, all the way across the screen and as fast
as my hand will go, and there is no "trail" of unpainted central widget areas.
That suggests to me that Qt must have a complete set of all the central
widget pixels stashed away somewhere.  So why do you get an empty
rectangle when the dialog box closes?

Given that things are as they are, I have found that the white rectangle
is in fact the default background color of the central widget and the time
for which the rectangle appears depends on what you do next in the app.
If I hit Cancel, the dialog box area is repainted much sooner than if I ask
to load a new level.  Similarly, drop-down menus stay "down" in ghost
form for more or less time, depending on what menu action you select.

So I suggest the following counter-measures for these ugly graphic effects:

1. Choose a background color for the central widget that matches your theme,
    e.g. brownish-dark-grey for Egypt, black for Nostalgia, border green for
    Geek City.  That way, the transient blank patches are less obtrusive.

2. Don't do what the dialog box or menu says immediately.  Act as if the
    dialog was cancelled or no action was selected on the menu, then use
    a single-shot timer with interval zero (or a QMetaObject::invokeMethod
    queued procedure call) to re-queue your rendering or re-painting
    activity, so that the hole gets painted over first.  This would take a
    split second longer, but would look a lot better imo.

I have implemented 1. in KGoldrunner and will commit it soon.  I have
not tried 2. yet, because it involves some re-structuring of code and
would take more than a few hours I suspect.

Hope this helps, Ian W.