| [INFO] | Channel view for “#xorg-devel” opened. |
| -->| | YOU (dkegel) have joined #xorg-devel |
| =-= | Topic for #xorg-devel is “End-user questions: #xorg | 7.3 in August 2007 | http://www.x.org/wiki/XDC2007Notes | X.Org in Summer of Code 2007: http://www.x.org/wiki/SummerOfCodeIdeas” |
| =-= | Topic for #xorg-devel was set by daniels on 06/11/07 13:51:44 |
| [INFO] | This
channel requires that you have registered and identified yourself with
the network's nickname registration services (e.g. NickServ). Please
see the documentation of this network's nickname registration services
that should be found in the MOTD (/motd to display it). |
| <Thunderbird> | hi dan |
| <ajax> | win32 might actually do exposures in a sensible way, unlike X |
| -->| | stringfellow (n=stringfe@ip56503c9f.direct-adsl.nl) has joined #xorg-devel |
| <daniels> | ajax: say it ain't so |
| -->| | Grummus (n=Grummus@i577A9F22.versanet.de) has joined #xorg-devel |
| -->| | julliard (i=julliard@wine.codeweavers.com) has joined #xorg-devel |
| <dkegel> | thunderbird, can you email me the scrollback? dank@kegel.com |
| <ajax> | but you would think automatic compositing would handle that... |
| -->| | truiken (n=jhawkins@207.47.98.129.static.nextweb.net) has joined #xorg-devel |
| -->| | ulrichc (n=ulrich@CPE0016b6dd092e-CM001225d8aa54.cpe.net.cable.rogers.com) has joined #xorg-devel |
| <Thunderbird> | julliard: could one of you explain the issue with child windows? |
| <fredrikh> | composite makes expose events pretty irrelevant |
| <Thunderbird> | they don't see our issues yet |
| <ajax> | seriously, if expose processing is the only problem, let's just make automatic compositing work |
| <ajax> | since it ought to work magically and for free already |
| -->| | jacek (n=chatzill@azm122.neoplus.adsl.tpnet.pl) has joined #xorg-devel |
| -->| | stefand (n=stefan@chello084112174163.20.11.vie.surfer.at) has joined #xorg-devel |
| -->| | philcostin (n=pac@host86-133-33-58.range86-133.btcentralplus.com) has joined #xorg-devel |
| -->| | coolbreeze (n=strawman@CPE0018f319c71e-CM0017ee620d0a.cpe.net.cable.rogers.com) has joined #xorg-devel |
| <ajax> | OMGHAX |
| <aaronp> | fredrikh: You still get expose events for non-redirected portions of the tree. |
| <aaronp> | E.g. a child window of a redirected window getting moved. |
| <ajax> | and you don't automatically composite recursively because.. |
| <aaronp> | because the windows have compatible visuals. |
| -->| | jwhite (n=jwhite@jwhite.codeweavers.com) has joined #xorg-devel |
| <ajax> | you can explicitly a-r any window you like, right? that's sort of the point. |
| <fredrikh> | and it would use too much pixmap memory |
| <aaronp> | implicit redirection only applies to windows whose visual "specialness" differs from its parent. |
| <fredrikh> | i actually think that's the main argument |
| <ajax> | all implicit redirection is automatic; not all automatic redirection is implicit |
| <daniels> | aaronp: and with keithp's patch, you also get expose events for manually-redirected children |
| <aaronp> | Oh, you're talking about client-requested automatic redirection? |
| <ajax> | aaronp: yes. |
| <fredrikh> | aaronp: that's true, but i think moving child windows isn't the most common scenario |
| <aaronp> | I was confused, sorry. |
| <ajax> | for that matter we could force the issue and turn on automatic compositing by default |
| <julliard> | the
problem we have with expose events is that windows apps expect all
child window operations to be synchronous, so we need to prevent them
from generating any async expose event |
| <daniels> | julliard: define 'synchronous'. |
| <julliard> | when the move/resize function call returns all repainting is done |
| <julliard> | (that includes potentially repainting across threads/processes) |
| <julliard> | so any expose event that is a result of a child move/resize needs to be ignored |
| <julliard> | but we can't do that because we can't know what triggered an given expose event |
| <ajax> | julliard: have you tried turning on automatic compositing for the bigwindow? |
| <daniels> | in
theory, if you absolutely needed that guarantee, you could grab the
server, sync, ignore exposes, move, sync, unignore exposes, ungrab
server. but, what ajax said. |
| <ajax> | because that ought to suppress pretty much all expose events except those resulting from map/unmap |
| <ajax> | yeah, server grabs make baby jesus' flesh fall off |
| <daniels> | indeed. |
| <daniels> | and not just the little bits in the hands and feet that make jesus, jesus. all of it. |
| <julliard> | i'm not familiar with automatic compositing, how would it change the behavior? |
| <clee> | julliard: with automatic compositing, expose events go away. |
| <clee> | except for, as ajax noted, map/unmap. |
| <daniels> | julliard: automatic compositing essentially means you're never obscured |
| <daniels> | julliard:
when a region gets unobscured (by moving/unmapping of a window above
it), the server will just copy the pixels you've been rendering |
| <daniels> | julliard: no expose events are sent |
| <ajax> | it's like backing store except without the suck |
| <dkegel> | ajax, you have a real way with words! |
| <dkegel> | Glad I'm not drinking coffee. |
| <ajax> | thanks! |
| <clee> | dkegel: ajax is the source of most of the quotes on my blog. |
| <julliard> | so how does it work with child windows? do you have to render the children individually? |
| <daniels> | ajax:
i can never remember backing store's semantics. wasn't it something
special like you can ask the server for backing store, but it can
cheerfully (and silently) ignore you? |
| <julliard> | (windows essentially doesn't clip children at all) |
| <daniels> | julliard: with automatic compositing, you get the exact same semantics as previous wrt child windows |
| <daniels> | julliard: it's just that the server essentially does an automatic save-under for you |
| <ajax> | daniels: can ignore you, but must generates exposes when it does |
| <fredrikh> | clee: maybe you can publish them as a book some day ;) |
| <daniels> | julliard: _manual_ compositing means that you get to produce the final image yourself, by composing the previous window |
| <daniels> | i don't know where 'previous window' came from. imagine i said something sensible there. |
| <stringfellow> | Hmm, how does that impact GL performance? |
| -->| | Cw (n=cw@h4604c785.area3.spcsdns.net) has joined #xorg-devel |
| <ajax> | uh, good question actually |
| <daniels> | ajax: surely the answer is unimpeded, since we don't have a way to redirect dri atm? |
| <ajax> | daniels: yeah, should be fine as long as we get the clipping dance right in the server, and i think we do |
| <ajax> | would be interesting to find out |
| <daniels> | i'd be pretty surprised to see it broken with automatic compositing |
| <daniels> | manual compositing, otoh ... |
| <julliard> | i'm worried about that save-under thing, how does it work with IncludeInferiors? does it update the save-under too? |
| <daniels> | julliard: pretty sure those semantics don't change from the uncomposited case |
| <ajax> | automatic compositing _should_
act like normal X but without any exposes due to clipping changes. i'm
pretty sure any case where it doesn't, can reasonably be considered a
bug. |
| <ajax> | of
course the irony here is that this will make wine apps look better than
native apps since you'll never see expose handling. weak. someone fix
gtk already |
| -->| | gravity (n=david@dsl092-079-075.bos1.dsl.speakeasy.net) has joined #xorg-devel |
| <daniels> | aiui
the only case where this changes is the clip for any window with
manually-composited children will include its children (i.e.
includeinferiors for children set to manual redirect). but a) that's
only with a patch that hasn't been merged yet, and b) you're not doing
that. |
| <--| | agd5f has left #xorg-devel |
| <daniels> | ajax: dibs on the gtk fixing, i need someone who can stomach both gdk and input. |
| <daniels> | (hacked on gdk once. that was sufficient penance.) |
| |<-- | Cw has left freenode (Read error: 104 (Connection reset by peer)) |
| -->| | libv_ (n=libv@231.147-246-81.adsl-dyn.isp.belgacom.be) has joined #xorg-devel |
| <fredrikh> | ajax: i don't think gtk uses X windows for child widgets, with a few exceptions |
| <daniels> | fredrikh: pretty sure he was talking about always using automatic compositing |
| <daniels> | xcompmgr -a ftw |
| <ajax> | fredrikh: sure, but it doesn't autoredir its windows, so you get to see expose processing |
| -->| | AMDPenguin (i=nobody@nat/amd/x-046511fd8b146a35) has joined #xorg-devel |
| <stefand> | does automatic compositing have any hardware requirements? |
| <gravity> | xcompmgr still merits a ftw in any case? |
| <daniels> | stefand: software |
| <stefand> | or does it just need up to date drivers / x server? |
| <ajax> | yeah, autoredir is all handled within the X server |
| <daniels> | gravity: in the case where it performs one x call, sure. |
| <stefand> | oh, cool |
| |<-- | jg has left freenode (Read error: 110 (Connection timed out)) |
| <gravity> | daniels: Ok, I didn't know there were any instances where it didn't suck |
| <daniels> | gravity: dude, if you have a radeon, enable exa (with a sufficiently up-to-date git pull), and run xcompmgr -a |
| <stefand> | daniels: so in theory it would even work on my 12 year old chips&technologies 65550? |
| <gravity> | daniels: Hrm, I'll give it a go on my laptop tomorrow. That might be fun. |
| <daniels> | gravity: the first time i did that, i spent like five minutes just dragging dialog boxes around. WHOOHOOOO 1993 BRING IT |
| <gravity> | hahahaha |
| <fredrikh> | ajax: well, isn't that more the responsibility of the window manager? |
| <daniels> | stefand: not just 'in theory', but it does. |
| <ajax> | fredrikh: i... guess? why would it be? |
| <fredrikh> | actually what we need is some way to sync painting on windows with the composite manager |
| <fredrikh> | so you never see anything half painted |
| <ajax> | gtk does have a finish frame protocol now |
| <ajax> | (thanks ssp!) |
| <ajax> | so yeah, you could do that. |
| <daniels> | fredrikh: clearly the answer is more indirection |
| <clee> | more cowbell |
| <daniels> | fredrikh: create a window pixmap, then the only operation you ever perform on your window is CopyImage |
| <ajax> | just
wire up a sync counter to the internal damage reporter and only let the
damage out to the compositing logic when the frame is done |
| <ajax> | "just" |
| <fredrikh> | ajax: the idea of a toolkit doing autoredirection on the root window seems a bit strange to me |
| <daniels> | ajax: hm, but then you're still requiring manual redirection of your own windows, no? |
| -->| | sxpert_ (n=sxpert@navsys.org) has joined #xorg-devel |
| <daniels> | fredrikh: s/the/its/ |
| |<-- | sxpert_ has left freenode (Client Quit) |
| <fredrikh> | daniels: i hope you mean CopyArea ;) |
| <daniels> | fredrikh: firefox gets no expose events, xedit still looks like crap, but no-one cares anyway |
| <ajax> | daniels: see, i always thought autoredir would inherit down through the window tree. |
| <Thunderbird> | you guys don't expect performance issues in GL apps if we would go this path? |
| <daniels> | ajax: right. so you redirect your app's top-level window, and it recurses. |
| <daniels> | Thunderbird: the consensus seems to be 'no, but feel free to prove us wrong' |
| <ajax> | Thunderbird: only if you're doing software GL, in which case, you now have two performance issues. |
| <ajax> | DRI should be fine |
| <daniels> | ajax: if you hit glcore, any composite-induced performance issues pale in comparison to the original one |
| <Thunderbird> | ok that's the most important one (most likely nvidia is fine too) |
| |<-- | CosmicPenguin has left freenode (Nick collision from services.) |
| =-= | AMDPenguin is now known as CosmicPenguin |
| <daniels> | ajax: anyhoo, seems that what would be most useful would be some kind of damage redirection? |
| <daniels> | ajax: imagine you could accumulate all your damage, and then post it whenever's convenient. say, at frame drawing. |
| <daniels> | ajax: this way, you fix automatic compositing, as well as external compositing managers. |
| <ajax> | i would have called that damage gating; redirection seems like a bad word to use anymore. |
| <daniels> | sure |
| <ajax> | so how would you decide how to gate? |
| <asyd> | S/ 7 |
| <asyd> | oups |
| <daniels> | in any case, that seems like the only way to fix the half-frame issue. |
| -->| | libv__ (n=libv@231.147-246-81.adsl-dyn.isp.belgacom.be) has joined #xorg-devel |
| <daniels> | ajax: the server wouldn't gate. punt to apps that specifically request it. |
| <gravity> | Could
someone post a log of the last few minutes? I missed the beginning of
this, and I'd love to know what the actual problem being solved is... |
| <daniels> | ajax: send damage notifications to the app, app calls xdamageadd at its leisure. |
| <daniels> | (though
i guess you still have somewhat of a sync issue: app sends xdamageadd,
app begins painting next frame, compositing manager gets scheduled in
and begins compositing ...) |
| <ajax> | daniels: yeah, that doesn't sound right. the app's just going to turn around and get the damage events telling it to paint... |
| <ajax> | i'm assuming here that the app wanting to redirect damage, is doing compositing at some level, which seems likely |
| <daniels> | ajax: er, damage events tell apps to paint now? |