December 2006 - Wine-Devel - list.winehq.org

Re: OpenGL as child windows

by Chris Robinson

On Sunday 31 December 2006 11:44, Mark Hatsell wrote: > Just wondered what would happen in the case of a non-X11 child window > partially overlapping an X11 OpenGL window? I guess this wouldn't work > still even with this solution. This could happen quite easily in an MDI > situation. I suppose the OpenGL window would overlap the non-X11 child window. But such a thing does not work now, nor will it ever as long as OpenGL draws directly to the main window. But this would only be an issue when the actual OpenGL window area is overlapped by something from the same parent window (a seperate popup MessageBox, for example, would still work fine). And even in Windows, OpenGL windows have problems when overlapped with other child windows.

Dec. 31, 2006

Re: OpenGL as child windows

by Roderick Colenbrander

> > These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine > > doesn't do), but rather, a child window of the main window used solely > for > > showing OpenGL on. I can't, in my admittedly limited knowledge, think of > > why > > it wouldn't work, and it should also help clear the problem Wine has > with > > Win32 child windows using OpenGL since they'd implicitly clip to the > child > > window extents, instead of trying to hack the scissors test. The X11 > child > > window for OpenGL would be completely transparent to the app (as in, > > opengl > > wouldn't announce its existance, and the rest of the code wouldn't care > > about > > it). > > Just wondered what would happen in the case of a non-X11 child window > partially overlapping an X11 OpenGL window? I guess this wouldn't work > still > even with this solution. This could happen quite easily in an MDI > situation. > > Mark > That would indeed be a problem. You could perhaps force that part to share the child window though that would cause other issues again. I'm not sure what pixel formats MDI apps in general use but perhaps they might need specific pixelformats for instance ones with the cap 'PFD_GDI_SUPPORT' to allow gdi rendering. If that's the case we just hide the GDI support cap and add a pixelformat with that cap set. When that pixelformat is used the current opengl behavior could be used. (Assuming our glScissors code would work correctly, this would get MDI running) Regards, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Dec. 31, 2006

Re: OpenGL as child windows

by Mark Hatsell

> These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine > doesn't do), but rather, a child window of the main window used solely for > showing OpenGL on. I can't, in my admittedly limited knowledge, think of > why > it wouldn't work, and it should also help clear the problem Wine has with > Win32 child windows using OpenGL since they'd implicitly clip to the child > window extents, instead of trying to hack the scissors test. The X11 child > window for OpenGL would be completely transparent to the app (as in, > opengl > wouldn't announce its existance, and the rest of the code wouldn't care > about > it). Just wondered what would happen in the case of a non-X11 child window partially overlapping an X11 OpenGL window? I guess this wouldn't work still even with this solution. This could happen quite easily in an MDI situation. Mark

Dec. 31, 2006

Re: appdb rating inflation

by Chris Morgan

On 12/31/06, Dan Kegel <dank(a)kegel.com> wrote: > The appdb says > "Only applications which install and run flawlessly on an out-of-the-box > Wine installation make it to the Platinum list" > But several platinum-rated apps seem to deserve > a silver or bronze rating. > > For instance, Call to Duty, > http://appdb.winehq.org/appview.php?iVersionId=3603 > has all sorts of caveats: > - Punkbuster enabled Multiplayer will not work > - Sound out of sync. > - Runs without crashes, but only if installed as root > - requires whacky third-party Loki installer; real installer > fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) > - "with alsa, the sound lags ~ 1 second behind the game.... if i > choose oss i got the 166 sound files missing error" > > And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, > also has lots of complaints / caveats / complicated howto's. > > Should we impose some standards on appdb ratings? > - Dan > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > Any app with sound issues shouldn't be rated platinum since it isn't playable without issues. Dan, are you an appdb admin? If you are interested in becoming one you can change the maintainer ratings for apps that are are misrated. Maybe we aren't clear enough on this page: http://appdb.winehq.org/help/?sTopic=maintainer_ratings since we don't say anything about how well an application runs under the "Platinum rating" but we do under the "Gold rating" description. Chris

Dec. 31, 2006

Re: appdb rating inflation

by Enverex

Dan Kegel wrote: > The appdb says > "Only applications which install and run flawlessly on an out-of-the-box > Wine installation make it to the Platinum list" > But several platinum-rated apps seem to deserve > a silver or bronze rating. > > For instance, Call to Duty, > http://appdb.winehq.org/appview.php?iVersionId=3603 > has all sorts of caveats: > - Punkbuster enabled Multiplayer will not work > - Sound out of sync. > - Runs without crashes, but only if installed as root > - requires whacky third-party Loki installer; real installer > fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) > - "with alsa, the sound lags ~ 1 second behind the game.... if i > choose oss i got the 166 sound files missing error" > > And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, > also has lots of complaints / caveats / complicated howto's. > > Should we impose some standards on appdb ratings? > - Dan Call of Duty didn't work at all last time I tried it but that was a while ago. Diablo 2 installs fine and works perfectly but it seems far too many rather dim people try and use it or make it out to seem like you have to do a lot to make it work. It works "out of the box". Even the copy protection works. Works in Single player, works in Multiplayer, works on Battle.NET, even works with mods. So it is deserving of a platinum (I can't find a fault with it). The "howto" is just for laymen because lots of people that have no idea how to use Linux were likely trying to install it all the time a while back. Same issue we're seeing now with WoW in the IRC channel. Ex

Dec. 31, 2006

Re: OpenGL as child windows

by Vitaliy Margolen

Dmitry Timoshkov wrote: > "Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > >> AFAIK there is no technical problems, only political ones. Wine no >> longer allows subwindows to be X11 windows. I've heard Alexandre >> Julliard won't accept such patches. > > That was a purely technical decision to get rid of X windows for child > Win32 windows, and has fixed numerous painting and z-order related > problems. If you or somebody else are really interested to go backwards, > show us the code which cleanly passes 'make test' in dlls/user32 and > simultaneously solves the problem for OpenGL child windows. > I'm not so sure that openGL windows behave the same way as GDI. Even native has lots of visual glitches with that. Some one said they act like an overlays - which might be true. In either case, what would stop us from at least considering this as a valid option limited to openGL only? Another BTW I have not seen a single test in user32 that involves openGL. Vitaliy

Dec. 31, 2006

appdb rating inflation

by Dan Kegel

The appdb says "Only applications which install and run flawlessly on an out-of-the-box Wine installation make it to the Platinum list" But several platinum-rated apps seem to deserve a silver or bronze rating. For instance, Call to Duty, http://appdb.winehq.org/appview.php?iVersionId=3603 has all sorts of caveats: - Punkbuster enabled Multiplayer will not work - Sound out of sync. - Runs without crashes, but only if installed as root - requires whacky third-party Loki installer; real installer fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) - "with alsa, the sound lags ~ 1 second behind the game.... if i choose oss i got the 166 sound files missing error" And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, also has lots of complaints / caveats / complicated howto's. Should we impose some standards on appdb ratings? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 31, 2006

Re: Resend: user32: fix return value in DialogBoxParamA if no resourcecan be found + simple test (try 2)

by Dmitry Timoshkov

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > As Dmitry Timoshkov (thanks for that) the SetLastError was not necessary. > Here's updated patch. Probably the problem is that you need also handle both FindResourceW and LoadResource failures the same way by returning -1, and change 'return -1;' later to 'return 0;' (for invalid parent) as MSDN suggests. All that needs to be tested as well. Also DialogBoxParamW needs to be fixed as well. Probably other dialaog APIs (like DialogBoxIndirectParamAorW) need a review regarding that. -- Dmitry.

Dec. 31, 2006

Re: OpenGL as child windows

by Roderick Colenbrander

> On Sunday 31 December 2006 00:12, you wrote: > > AFAIK there is no technical problems, only political ones. Wine no > > longer allows subwindows to be X11 windows. I've heard Alexandre > > Julliard won't accept such patches. > > These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine > doesn't do), but rather, a child window of the main window used solely for > showing OpenGL on. I can't, in my admittedly limited knowledge, think of > why > it wouldn't work, and it should also help clear the problem Wine has with > Win32 child windows using OpenGL since they'd implicitly clip to the child > window extents, instead of trying to hack the scissors test. The X11 child > window for OpenGL would be completely transparent to the app (as in, > opengl > wouldn't announce its existance, and the rest of the code wouldn't care > about > it). > The subwindow would be created from within the opengl code (e.g. wglCreateContext / SetPixelFormat). That is where it happens on Windows too and on Windows OpenGL also uses some sort of overlay. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Dec. 31, 2006

Re: ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION

by Dmitry Timoshkov

"Andreas Mohr" <andi(a)rhlx01.fht-esslingen.de> wrote: > The STATUS_ILLEGAL_FUNCTION name was rather misleading to me since it doesn't > indicate at all that it's supposed to be pipe-related > (however it's within the numeric range of many other pipe status codes!). > So, given that this is mainly a pipe status code after all I'd say that's > the best we can achieve right now. I haven't found anything more close is the PSDK. > Of course, what really matters is what the receiving Win32 side *usually* > expects after we encountered ESPIPE, and this might turn out to differ > from your conversion ;). > (is there any indication that RedAlert checks for a specific status code??) Looks like that my change didn't actually affected RedAlert at all, at least it was still functioning in my limited test session. -- Dmitry.

Dec. 31, 2006