| [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. |
| * mlankhorst | misses 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. |
| * jwhite | stamps 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 |
|