URL irc://freenode/winehackers Mode +tn Users 82, 12@, 0%, 0+
Topic winehq.org programming - Users go to #winehq - Wine 0.9.38 released
#winehackers
[INFO]Channel view for “#winehackers” opened.
-->|YOU (dkegel) have joined #winehackers
=-=Topic for #winehackers is “winehq.org programming - Users go to #winehq - Wine 0.9.38 released”
=-=Topic for #winehackers was set by Thunderbird_ on 06/01/07 11:10:08
[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
<dkegel>howdee!
<Griswold>hihi
<jwhite>dkegel, waiting on ulrichc to start us off.
* mlankhorstmisses a whole lot of tiny commits in last wave
<ulrichc>sorry. the current solution in winehq suffers from a couple of problems
<dkegel>ulrichc, please call this meeting of the 1.0 or Bust society to order...
<ulrichc>1) glxswapbuffers doesn't honour the viewport
<ulrichc>2) we can't handle different pixel formats
<ulrichc>I tried various gl extensions to handle 1 but couldn't come up with a reliable solution
<jwhite>and the hopes of an X extension addressing #2 is?
-->|cjsoftuk1 (n=chris@user-54414b87.l5.c5.dsl.pol.co.uk) has joined #winehackers
<ulrichc>not sure
<--|cjsoftuk1 has left #winehackers
<jwhite>and Thunderbird has a patch that addresses this by going back to the old behavior?
<Thunderbird>well, it is total evil
|<--blergit has left freenode (Read error: 110 (Connection timed out))
|<--playa has left freenode (Remote closed the connection)
<Thunderbird>basically what it did was inject an x11 client window when the need of opengl is detected
<ulrichc>I'll let Thunderbird explain his approach ;-)
<Thunderbird>and then some voodo is required for positioning the window ..
<Thunderbird>for positioning it also requires you to walk through all parents of a win32 child window to get the real position relative to its toplevel parent window
<jwhite>would it be complete bullshit to rationalize that opengl child windows are less likely to have the sort of timing/message coordination problems that triggered the wm rewrite?
<jwhite>iow, is a little bit of evil okay in this case?
<Thunderbird>it is not acceptable
<Thunderbird>the main issue according to julliard is X event related
<julliard>yes, expose events specifically
<Thunderbird>the possibility exists that the child window is injected from a different process
<julliard>as soon as you introduce child windows you get async expose events, and windows apps don't like this at all
=-=EmuandCo is now known as Emu|AFK
<dkegel>can the async events be buffered somehow?
-->|truiken (n=jhawkins@207.47.98.129.static.nextweb.net) has joined #winehackers
<jwhite>I was wondering: could you create a real child window, but discard / pass through all expose events?
<julliard>the problem is we can't distinguish expose events caused by child windows and "real" expose events
<stefand>the other problem with just a child window for opengl is that it doesn't solve the problem if the child window is overlapped by a non-gl child window
<Thunderbird>correct but for the majority of the apps I tried this wasn't a problem; but indeed for some it is
<julliard>yes for this and other reasons you really need to have x windows for all children not just the opengl ones
<dkegel>Sounds like it's all or nothing, then...
<Thunderbird>(though on windows child window rendering has issues too)
<kblin>hi dan
<dkegel>hi, kai. we're discussing what to do about opengl...
<jwhite>okay, so one completely yucky solution is to have a 'mode' toggle in Wine (sort of like the desktop mode). julliard, I presume that's a horrendous idea?
<kblin>just reading scrollback
<julliard>jwhite: not really possible
<jwhite>ah, you're just saying that because you hate it so much <grin>
-->|stringfellow (n=stringfe@ip56503c9f.direct-adsl.nl) has joined #winehackers
<Thunderbird>you don't know in advance when you need GL
<stringfellow>hi
<julliard>well it requires changes all over x11drv so you basically have to maintain two versions
<Griswold>Hello stringfellow :)
<jwhite>yah
<jwhite>okay; I remain completely uncool with the notion that there is a whole category of apps that Wine simply cannot run.
* jwhitestamps his feet
<dkegel>wasn't there some talk of having a full-on opengl backend anyway, once upon a time?
<dkegel>the opengl folks certainly think opengl is up to all 2d tasks
<madewokherd>I'm guessing maintaining two versions is a bad idea then or you wouldn't have suggested it ;)
<Thunderbird>you could start a whole opengldrv
<stefand>dkegel: that came around when I had that opengl gdi idea for wined3d I think
<Thunderbird>but then how do you want to do window management stuff?
<stefand>dkegel: the problem is that it needs pretty advanced gl features to do everything
<Thunderbird>perhaps you could get away with GLX_EXT_texture_from_pixmap which would allow you to use the win32 window as a texture in opengl
<julliard>dkegel: opengl is fine for gdi but doesn't help for user stuff
<Thunderbird>but the main issue is that most drivers don't support it
<julliard>so you still have expose events and such to deal with
<madewokherd>naive uninformed question: is this impossible to fix properly then?
<jwhite>madewokherd, this is a brainstorming session; currently there is no clear solution.
<jwhite>the hope is to find something, anything :-/
<dkegel>compiz et al require the GLX_EXT_texture_from_pixmap feature, so there's lots of market pressure to support it
<KittyCat>I'd favor the idea of pbuffers (put all drawing to them, and keep the win32 window updated with the pbuffer's front buffer), and ati and nvidia support it.. but I hear it's not that good.
<Thunderbird>sure but lots of old drivers (old hardware) don't support but you still have pixelformat issues (which are getting more and more important)
<Thunderbird>dri drivers don't support it ...
<stefand>KittyCat: I've always hated that idea for performance reasons
<dkegel>we could simply refuse to run opengl apps if that extension isn't there. (Evil, but might be ok.)
<stringfellow>and if you want any kind of performance for d3d or gl applications that's going to suck, basically
<madewokherd>I'd complain
<stefand>yep; don't expect more than 20 fps on 640x480 that way
<KittyCat>well, for optimization, if you're not writing to it's front buffer, you could just dirtify the window whenever a flip occurs
<madewokherd>wait, no, I have it so I wouldn't complain
<Thunderbird>the only real solution in my opinion would be to return X11 child windows for everything but that would return lots of other issues
<stefand>madewokherd: watch out for client gl vs server gl extensions. You need both
<ulrichc>we could also investigate the possibility of writing an x extension to deal with the pixel format issue
<jwhite>what would we need from such an extension? the ability to treat a portion of an opengl window as though it were a separate window?
<kblin>stefand, radeon seems to have it
<stefand>kblin: nope. Only client, not the server(dri that is. fglrx has it, but its broken)
<Griswold>Slightly off topic: If we want an X extension, perhaps we could ask for a common way to query video card info.? (Eg. amount of memory.)
<Thunderbird>yeah a sort of 'virtual window' extension but I doubt they would except something like that
<madewokherd>glxinfo says I have both, but I do have a radeon card..
<Griswold>Slightly off topic: Or perhaps a kernel (/proc?) interface would be better?
<Thunderbird>and I think it would be a hell for driver writers too
<jwhite>Thunderbird, actually, I think the xorg guys are a lot more giving than you think.
<kblin>stefand, I've got both
<jwhite>at this point, we might almost want to dub it the Wine extension
<jwhite>the key question, though, is whether or not it would do any good.
<Thunderbird>we would still have positioning issues
<dkegel>griswold: if you propose making it use xml, I'm going to hurt you :-)
<Griswold>dkegel, hehe :P
<Thunderbird>and second overlapping would need to be fixed as well
<Griswold>dkegel, I was thinking on a little, tiny api, actually
<stringfellow>Griswold: It needs to work for remote X as well...
<julliard>Thunderbird: well you don't want real windows, you want the ability to define clipping and pixel format independently from the x window
<Griswold>I was basically thinking of an X lib. (very small) that would have something like: XGetVideoCardName() (returns a string), or XGetVideoCardMemory() (returns an int), etc.
<Thunderbird>what would you like the extension to do? allow you to change the pixelformat of a portion of the X window?
-->|Mongoose (n=mongoose@75-120-224-106.dyn.centurytel.net) has joined #winehackers
<julliard>yes, specify these things per device context instead of per window or something along those lines
<madewokherd>by independently do you also mean potentially drawing outside where the X window is?
<stefand>Thunderbird: how about defining an opengl overlay(position + format)
<Thunderbird>Griswold: a function like that would be useful for wine but in reality it isn't that useful; for opengl you don't want to rely on the amount of memory as it doesn't require it
<Griswold>Thunderbird, yes, I understand that. However, it seems it would be easy enough to implement
<Griswold>And game companies might want it also
<madewokherd>because that would be useful for ddraw..
<Thunderbird>an opengl overlay window would be cool too; but I think it is more trickier to get in; if it is part of Xorg it will be available much sooner
<Thunderbird>we could invite an xorg dev .. I know one from nvidia which might be around ..
<Griswold>Anyhow, I was asking for it as an X api, not an OpenGL api :)
<Thunderbird>he was one of the guys behind GLX_EXT_texture_from_pixmap
<dkegel>Should we ask Keith Packard to join us?
<Thunderbird>that could be useful
<dkegel>Perhaps in a followup chat?
<Thunderbird>keith is online right now
<Thunderbird>(keithp is his nick)
<dkegel>Can you invite him?
<Thunderbird>lets see if he responds
<jwhite>ulrichc, when you spend some time desinging an extension, were you mostly focused on issue #1? or did you consider #2 as well?
<jwhite>didn't you get to the point of having a discussable prototype?
<ulrichc>just 1. I didn't even consider 2
|<--stephank has left freenode ("*Poof!*")
<jwhite>ah, I see.
<jwhite>but you felt that #1 was tractable with an extension, right?
<ulrichc>yes I think so
<dkegel>I just invited keith, too, by replying to a message on this topic from a year ago
<stefand>if we create X child windows for win32 windows to address the pixel format issue and the clipping, do we have to use them for processing events too?
<dkegel>iow, this is deja vu all over again :-)
<stefand>can't we ignore the events or forward them to the main window to handle them in the way we do it now?
<Thunderbird>upto now keith doesn't respond
<BBrox>BTW (last time I looked that was AGES ago), 'Xv overlays' had the same issue than GL... No idea if news video players use rather D3D and YUV textures though for drawing :-)
<stringfellow>D3D and pixel shaders :-)
-->|philcostin (n=pac@host86-133-33-58.range86-133.btcentralplus.com) has joined #winehackers
<--|philcostin has left #winehackers ("Client exiting")
-->|philcostin (n=pac@host86-133-33-58.range86-133.btcentralplus.com) has joined #winehackers
<stefand>hi philcostin
<stringfellow>hi
<philcostin>hi stefand :D
<philcostin>, stringfellow
<philcostin>had a little break :D
<Enverex>Jesus Christ. Apples Safari browser is in the queue FIVE TIMES.
<philcostin>got some stuff done in life 1.0
<philcostin>now it's time for me to look at A4R4G4B4 sRGB :D
<jwhite>hrm. we seem to be losing steam. ulrichc: question - do you understand our requirements enough to write an email summarizing them?
<jwhite>I'm wondering if we can take this to email; wine-devel and whatever the appropriate xorg ml would be.
<Griswold>Enverex, haha
<dkegel>Yes, let's do a summary email, then work towards a second chat, perhaps, with Keith
<Thunderbird>one of the issues they will have according to an Xorg dev, is basically the same as we had using the 'x11 child window' injection method
<ulrichc>jwhite: yes I can send one to wine-devel
<KittyCat>what if winex11 had a compositing mode? so if you had on a compositing mode, everything would draw to pixmaps, then be composited onto the main wine window (allowing for pixel formats/etc), and with it off, it behaves as it does now (buggy, but not unusable for most games)
<stefand>can we fix the pixel format issue by simply recreating the root window if a different pixel format is requested?
<jwhite>I'd also like to see a thread about the difficulties of having child windows.
<dkegel>stefand, yeah, e.g. we could go all the way to 32 bits per pixel on first mismatch?
<dkegel>(to be blunt and simple)
-->|kommerck (n=Leon@erft-4db39170.pool.einsundeins.de) has joined #winehackers
<stefand>dkegel: right now we try to create a pixelformat which can do everything, then take away feature by feature if it fails
<stefand>dkegel: that makes apps happy in the way that it delivers everything it wants, but it doesn't make them happy if it checks the real properties
<KittyCat>recreating the window isn't possible since the main window may already have things on it, and keeping everything wync'd between destruction/recreation would be pretty much impossible
<KittyCat>*sync'd
<stefand>KittyCat: I don't know how much effort it would be to save the state, recreate the window, restore the state. I was thinking mainly about wined3d where I wrote some patches which allowed recreating the gl context that way. But I have no idea about x11drv
<KittyCat>julliard told me that a while ago
<KittyCat>I haven't looked too much into it personally, but it doesn't look like it'd be easy, if possible
<stefand>Thunderbird: could we address the pixel format issue by lying to the app?
|<--BBrox has left freenode ("ZZzz")
<stringfellow>What was the problem with using X windows for GL windows only again?
<stringfellow>I know there was some issue, but not sure what it was anymore :-/
<KittyCat>it requires too much hacking for the gl child to get all the data it needs
<stefand>Thunderbird: like the app says "Give me a 16 bit pixel format with 1 bit of stencil". We have a 32 bit format with 24 bit of depth and 8 bit stencil. We give it our format, and when it asks what the format exactly looks like we give it back the description it wanted
<KittyCat>so it knows where to position itself, etc
<stefand>stringfellow: it would be an all or nothing issue
<stefand>stringfellow: and that invites the whole set of issues back that resulted in the wm rewrite
<Thunderbird>julliard: could you join #xorg-devel? they are asking what we actually want to have
<KittyCat>stefand, sounds too risky to lie. especially with things like stencil since that has specific behaviors
<KittyCat>eg. value clamping and wrapping
<stefand>KittyCat: wrt the depth stencil we'd have to watch out regarding the depth stencil wrap. Not sure if thats possible though
<dkegel>Heading over to xorg-devel to see what all the noise is about
<KittyCat>and even if you fooled the app, you wouldn't fool the player that could see the color depth is wrong or there's no multi-sampling, or there's no aux buffers, etc
<stefand>KittyCat: wrt the color and depth precision there would be at worst a performance issues if the colors have to be converted from a8r8g8b8 to r5g5b5
<stefand>KittyCat: obviously we'd only fool the app downwards. If it requests 32 bit color and we didn't get 32 bit color we say no
<stringfellow>it won't really help for eg. FSAA
<KittyCat>the app has to specify the depth it reads the color data from anyway.. that's not an issue
<stefand>that would be the correct answer even.
<Thunderbird>dkegel: http://roderick.student.utwente.nl/xorg-devel.log
<stefand>wrt FSAA its not a terribly pressing issue. we could make it a winecfg setting
<KittyCat>opengl is designed to not be picky about not getting the specific color depth you request
<stefand>exactly
<Thunderbird>well but WGL extensions are ..
<Thunderbird>various programs don't expect to see only a small amount of formats
<KittyCat>you can be picky, sure.. but the app isn't supposed to be for the color buffer
<Thunderbird>on windows you easily have 100 around
<dkegel>thunderbird, thanks. Favorite quote: "<clee> I'm going to vote that you guys put down the crackpipe"
<KittyCat>and certain things like the z-buffer depth and stencil depth can have a huge visual impact, so you can't really lie about them and expect to get away with it
<Thunderbird>the nvidia guy (aaronp) is reading the backlog from xorg-devel; so if AJ could highlight my errors
|<--Nonal has left freenode ("I am going away")
<stringfellow>:-)
<Thunderbird>aaron is asking me now for a clear description too
<stefand>KittyCat: would there be a problem with lying downwards? ie we have a 32 bit depth buffer and tell the app its a 16 bit one?
<julliard>Thunderbird: could you please send me the backlog then?
<Thunderbird>sure, http://roderick.student.utwente.nl/xorg-devel.log
<julliard>thx
<KittyCat>stefand, potentially you could (things might start z-fighting that weren't before), but you never know without trying
<Thunderbird>basically they are wondering why we can't use X11 child windows (basically in the EVIL way)
<KittyCat>I also don't think an X extension is the way to go. having an X extension is all well and good.. as long as drivers support it
<jwhite>I have to run; have to catch a plane :-/. ulrichc/julliard: I'd appreciate it if you could summarize any results via email.
<KittyCat>and there's already X and GL extensions waiting to be supported that'd work
<stefand>ya, I dislike the idea too
<Thunderbird>that's the downside ..
<KittyCat>I think the best idea would be some kind of compositing method. having an offscreen pixmap to draw to would give you the pixel formats and solve the flip issue; and you could keep the non-compositing method around for drivers that aren't yet up to speed
<stefand>how do you composit? On the gpu side, in opengl? Then you get the shape issue again(and have to convert the pixel format somehow)
<KittyCat>could probably even leverage the composite extension so that it can be done on the gpu
<stefand>on the cpu side there's a major performance hit(unless you have a quadro / firegl card)
<dkegel>Next favorite comment from xorg-devel: "ajax> yeah, server grabs make baby jesus' flesh fall off"
<Thunderbird>performance is the most scarry part
<stefand>KittyCat: we could composit on the gpu by drawing to a fbo / pbuffer or even the back buffer, then read to a texture and draw it to the front buffer with the scissor test on
<stefand>if needed draw more than one rectangle
|<--madewokherd has left freenode (Read error: 60 (Operation timed out))
<stefand>drawing on the back buffer wouldn't help the pixel formats though, but that could be a fallback to old cards
<KittyCat>but that could potentially give you a front buffer and back buffer that don't have the same visual
<KittyCat>I doubt many apps would like that
<KittyCat>and it has to deal with the scissors hack (which I contend to be just as ugly as the child window hack, if not worse :P)
<KittyCat>unless the back buffer has the same size as the front buffer/main window, you'd have positioning issues
<KittyCat>given that the scissors test and viewport effects both the front and back buffers the same, they'd need to be the same size
<stefand>KittyCat: the app never has to see the real front buffer
<KittyCat>in opengl, you can select it specificly
<KittyCat>for both reading and writing
<stefand>ya, we'd have to hook glDrawBuffer and glReadBuffer and do something special about reading / drawing if GL_FRONT is selected
<KittyCat>more hacks/overrides..
<stefand>reading would need position correction, then read from the real front buffer
<KittyCat>it also wouldn't help apps that don't use a doublebuffer visual for the window
<stefand>if apps don't use doublebuffering themselves its easy... just draw to an offscreen front buffer and copy it on every draw(or vsync)
<stefand>double buffer + front buffer access is nasty
<stefand>unless we can create a double buffered pbuffer or fbo
<Thunderbird>I fear that the solution suggested by the xorg guys has performance issues
<Thunderbird>that the endresult basically will be that they create 'pbuffers' or something like that instead of us
<KittyCat>if we can't revert back to 1:1 child windows, then offscreen rendering is the only way I can see to cleanly solve it
<KittyCat>either for all child windows, or just GL ones
<Thunderbird>though composition will still be quite fast
<Grummus>can't you test the performance hit right now by turning on a compositing window manager? the wine windows should be forced to compositing then or?
<Thunderbird>people are playing games like doom3 at nice speeds; there's a slight performance loss I think (it would need to be tested)
<Thunderbird>just test this performance in a native game like ut2004 or doom3/quake4
<KittyCat>on my nvidia card, there's little speed degradation in a d3d app under wine with beryl
<Thunderbird>run a timedemo without composition and once with composition
<KittyCat>there's a small speed loss, but nothing to cry over
-->|CoolBeer (n=hightowe@ti541210a340-4048.bb.online.no) has joined #winehackers
<stringfellow>Hmm, last time i tried beryl with rthdribl it about halved the fps :-/
<KittyCat>morrowind is just above marginally playable for me normally, and is still playable in beryl
<KittyCat>with a gffx 5500
<Thunderbird>but nvidia has good offscreen rendering performance; not sure what happens if you do the same on ati
<stringfellow>Does ati even support composite yet? :-)
<Thunderbird>we would need good benchmarks; but upto now it looks like the most promising solution
<KittyCat>the current method can be left as a fallback 'til ati and nvidia get their acts together
<stringfellow>accelerated, that is
<Thunderbird>their drivers do I think
<KittyCat>*ati and intel
<Grummus>ati supports comositing / texture from pixmap only in xgl afaik
<KittyCat>we don't really need texture_from_pixmap
<KittyCat>we just need accelerated rendering to pixmaps
<Grummus>but compositing in the xserver needs texture from pixmap i think?
-->|CheekyBoinc (n=foobar@p5092052C.dip0.t-ipconnect.de) has joined #winehackers
<KittyCat>for opengl compositors, yes
<KittyCat>and having that extension is a likely indicator that rendering to a pixmap is accelerated, although it's not the only sign to look for
<KittyCat>it could still be slow with it, and it could be accelerated even without it
<Thunderbird>julliard: have they been able to convince you? (most of us don't know these X details)
<philcostin>is that the child window finally maybe solved? maybe?
<julliard>Thunderbird: i have no idea if it's going to work, but it's certainly something worth experimenting with
<Thunderbird>well .. it is tricky to implement in wine
<KittyCat>I think having it use an offscreen pixmap may help D3D in that you can pass it back with the HDC and have standard X calls run on it, without needing to read from opegnl's screen
|<--qwertymn has left freenode (Read error: 110 (Connection timed out))
<Thunderbird>ulrichc: are you going to take it from here on?