[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 170462] Momentary video garbage upon drawing (any) new object
From:       Rex Dieter <rdieter () math ! unl ! edu>
Date:       2008-12-22 18:16:36
Message-ID: 20081222181636.300D81320F () immanuel ! kde ! org
[Download RAW message or body]

http://bugs.kde.org/show_bug.cgi?id=170462


Rex Dieter rdieter math unl edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rdieter@math.unl.edu
             Status|RESOLVED                    |REOPENED
         Resolution|DOWNSTREAM                  |




--- Comment #54 from Rex Dieter <rdieter math unl edu>  2008-12-22 19:16:31 ---
After speaking with fedora's X maintainer, I am not convinced that suggesting
downstream removal of the aforementioned X server patch is the best way
forward.

Now, my X-protocol-fu is lacking, so some of this is beyond my current complete
understanding, but ajax outlines what seems to be another sensible
fix/workaround:

 <rdieter> ajax: got a sec to comment on the origins of
107_fedora_dont_backfill_bg_none.patch , and how it relates to
http://bugs.kde.org/show_bug.cgi?id=170462 ?
 <ajax> it's a performance hack for compositing
 <ajax> the problem is that windows can have their background pixmap set to
"None", which means something vaguely like "don't draw a background at all,
just reuse the bits underneath wherever the window got mapped"
 <rdieter> it seems to have side effects...
 <ajax> no kidding!
 <ajax> in Composite there's no strong notion of "the bits underneath where you
got mapped"
 <ajax> since the compositor could map you anywhere
 <ajax> trying to do what the protocol says is intensely painfully slow since
it's a readback from the card and those aren't fast
 <ajax> so what gnome quite sensibly does is tells the compositor not to show
the window contents until they're painted, using the same sync protocol that
window resizing uses.
 <ajax> and then the server just doesn't define initial window contents when
the window is both redirected and bg=None
 <rdieter> so it wouldn't be wrong to assert there's an issue/buglet here (in
kde) still, and the xorg patch is simply helping to expose it?
 <ajax> it's sort of ugly no matter what you do, which is why we're still
carrying that patch four releases later instead of having it upstream. 
anything you do here is wrong.
 <ajax> you're either breaking protocol semantics that have been good for
twenty years, or you're screwing performance.
 <ajax> rdieter: i'd say kde should do the sync protocol for mapping here, yes.
 it'll make it look right on servers with this hack, but it'll also look better
on unpatched servers since you won't see the menu in mid-draw


And another alternative:
 <mclasen> ajax: is this something you could negotiate at connection setup ?
 <ajax> mclasen: mm.  possibly.
 <ajax> you'd need to fix the toolkits to ask for protocol 11.1, i suppose.
 <mclasen> ajax: alternatively, invent a new NONE-I-MEAN-IT special value
 <ajax> yeah.  composite could define a magic pixmap that meant
suppress-backfill instead of the historical None value
 <ajax> and then the server would just treat it like None when the window
wasn't redirected.
 <ajax> that's not the worst idea ever.
 <ajax> and if we're doing that, we should probably just return the
CompositeNone pixmap in the CompositeQueryVersion reply so you skip a round
trip.



p.s. Apologies for longish-quasi-spam-to-bugzilla here


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]