April 2007 - Wine-devel - list.winehq.org

OpenGL child windows [RFC]
by Roderick Colenbrander 13 Apr '07

13 Apr '07

Hi, This is an updated version of the child window patch from Chris Robinson. I have added some fixes to it which were found by testing it with lots of programs. Windowed OpenGL Several options have been discussed over the years for solving the windowed opengl issues. The lazy option was to use pixmaps but you would lose hardware acceleration. A better way but similar was the use of pbuffers but still they are poorly supported by most drivers (only Nvidia has decent support). One of the most attractive solutions is the use of glScissors/glViewport changes. This path works now if you apply ulrich his latest patch which is in bugzilla (2398). Though for optimal performance you need specific opengl extensions. Second a number of standard opengl calls requires changes and some aren't done yet (glReadPixels and friends) but right now it is one of the best solutions. Another way of solving the windowed opengl problem is by using X child windows for the opengl window. In the end this results in the same as ulrich his glScissor work but with the advantage that it should work fast on all opengl implementations as it doesn't require special extensions. Further it doesn't require the patching of opengl calls. OpenGL pixelformats Next to the windowed opengl issues, there's the pixelformat limitation in Wine. Right now only one pixelformat can be used. Most programs use ChoosePixelFormat using which you can request a pixelformat but the call isn't guaranteed to give you back what you want. For this reason most programs aren't very critical. These days more and more programs are more critical. They use wglChoosePixelFormatARB which does give you what you want or programs enumerate all pixelformats using DescribePixelFormat and choose what they want. Anyway the issue is that the single pixelformat isn't enough anymore. A recent report from WoW on intel drivers is a proof of this http://bugs.winehq.org/show_bug.cgi?id=7866. The game didn't like the single format exported by Wine. Another example is the IKEA kitchen planner tool which uses DescribePixelFormat to enumerate all formats. It expects to find a match in a format. Right now it doesn't find any match and calls SetPixelFormat with iPixelFormat=0 (which is invalid). Like the above two programs there are many other programs with issues due to pixelformats. I believe that perhaps a few of them are fixable (by adding more hacks or by lieing to programs). If we had more pixelformats, I think the issues could be fixed. OpenGL child windows would fix this issue as the child doesn't have to use the same pixelformat as its parent (!). Summary If we would use OpenGL child windows in Wine that would fix most windowed opengl issues and second it would allow us to use more pixelformats as a child window doesn't have to use the same pixelformat as its parent. Patch As mentioned before the patch was mainly made by Chris Robinson and I have added a few fixes to it to make it more compatible. Bascially a child window is allocated for a hdc during SetPixelFormat which needs to be called on every hdc before it can be used with opengl. That's basically the biggest change to the opengl code. For the rest some x11drv calls like SetWindowPos had to be patched in order to move the child window when needed. Below you can find a list of tested programs and the results. As you can see it works correctly for most of the tested programs. Three of the tested programs don't work correctly of which two are not related to the use of child windows, so overall the result is good. I'd like to know of more programs that work / don't work and I like feedback on the patch. Properly working programs: - Blender - Google Earth - Google SketchUp - Lightwave 6 + 9 - MilkShape3D - Terragen + Terragen2 - VLC opengl plugin - Valve Hammer tool - Weatherscope - Q3Radiant Unfixed programs: - Truespace 6.5; The program uses OpenGL for its main window and uses some floating win32 toolbars. The child window obscures them, perhaps the SHAPE extension for X can be of any help here to cut parts away. Other broken apps not child window related: - NWN Model viewer; The program seems to do be using WGL in an illegal way but seems to get away with this without any failures on Windows. I don't know what's going on. It also never worked correctly before when there were X windows. It now behaves the same as before. Using ulrich his patch it works but that's basically an 'accident'. It isn't because the code is fixed. - IKEA kitchen planner; The program uses multiple child windows one for a 3D preview which works fine and it uses one for drawing on a grid. When drawing things on the grid, the objects quickly disappear. There's some buffer swapping issue I guess. The same happens without the child window patch and using ulrich his patch. So the issue is not related to child windows. Regards, Roderick Colenbrander -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

2 2

Re: wined3d: Consolidate all existing enablings of SFLAG_INSYSMEM in surface.c into one easy line
by Stefan Dösinger 13 Apr '07

13 Apr '07

Am Freitag 13 April 2007 00:28 schrieb Phil Costin: > This patch removes the need to manually set SFLAG_INSYSMEM after a call to > surface_download_data. It should be set by the function. - /* Mark the local copy up to date if a full download was done */ - if(This->lockedRect.left == 0 && - This->lockedRect.top == 0 && - This->lockedRect.right == This->currentDesc.Width && - This->lockedRect.bottom == This->currentDesc.Height) { - This->Flags |= SFLAG_INSYSMEM; - } This is not correct. This path is for render target locking, and it does not call surface_download_data, so you can't remove that.

2 1

Re: [2/2] wined3d: Remove usesFog flag from IWineD3DVertexShaderImpl
by Stefan Dösinger 13 Apr '07

13 Apr '07

Am Donnerstag 12 April 2007 19:49 schrieb Fabian Bieler: > Remove the usesFog flag and replace it with a 'method' as suggested by Ivan > Gyurdiev. So I'm ready to start yet another design flamewar here :-) Honestly I do not really agree with getter methods like this inside WineD3D. Yes, they do hide the implementation details, namely how the flag is stored. Yes, they do encapsulate data, like the Object Oriented Programming model says. But honestly, how much use is it to do a function call just to read a value inside wined3d? I don't argue that we should make wined3d internals visible to outside wined3d. But inside wined3d, my personal preference is to just access the implementation structure directly. How much abstraction does such a function give us at the cost of performance? In both cases the state management code has to know an internal of the shader code, wether the shader writes to the fog coordinate. This is something only the shader should need to know, no matter how it is accessed. Why do we need it? Because the way fog works with shaders requires that either the shader sets fog params or the code setting fog params has to know about the shader. We can't change that. There are many more examples like surface sizes in the viewport and SetRenderTarget code, ... ------------- In case of the foggy shader thing, I think we can get rid of that by just setting up the fog start and fog end when a shader is used and fog is on, no matter if the shader actually uses the fog. May even be faster in the end. Other than that, I think that the shader fog code is not quite right either, since if we need the foggy shader setup depends on the fogtablemode setting. But other simmilar cases still remain.

2 2

Re: ole32: Void functions should not return a value
by Robert Shearman 13 Apr '07

13 Apr '07

Andrew Talbot wrote: > diff -urN a/dlls/ole32/rpc.c b/dlls/ole32/rpc.c > --- a/dlls/ole32/rpc.c 2007-03-28 12:43:32.000000000 +0100 > +++ b/dlls/ole32/rpc.c 2007-04-12 20:20:48.000000000 +0100 > @@ -1352,7 +1352,7 @@ > TRACE("ipid = %s, iMethod = %d\n", debugstr_guid(&ipid), msg->ProcNum); > > params = HeapAlloc(GetProcessHeap(), 0, sizeof(*params)); > - if (!params) return RpcRaiseException(E_OUTOFMEMORY); > + if (!params) RpcRaiseException(E_OUTOFMEMORY); > > hr = ipid_get_dispatch_params(&ipid, &apt, &params->stub, &params->chan, > &params->iid, &params->iface); > @@ -1360,7 +1360,7 @@ > { > ERR("no apartment found for ipid %s\n", debugstr_guid(&ipid)); > HeapFree(GetProcessHeap(), 0, params); > - return RpcRaiseException(hr); > + RpcRaiseException(hr); > } > > params->msg = (RPCOLEMESSAGE *)msg; > You've changed the code paths here. -- Rob Shearman

4 4

RE: locales, unicode and ansi with msvcrt (bug 8022)
by Ann & Jason Edmeades 13 Apr '07

13 Apr '07

>What your test app is doing? It probably needs a test under Windows to >see in which encoding (ANSI/OEM) a not unicode app should receive input >via a pipe. Sorry, just realized I had not addressed your last comment - Can you expand on this sample test please and I'll do some experimenting. How do you mean a pipe (just stdin?) and what would this be showing beyond the straight file i/o case (My original test does straight writes to the console, and to a file). Also, for example, any suggestions on how to tell OEM from ANSI, and on telling the codepage used for the conversions. Thanks Jason

2 1

locales, unicode and ansi with msvcrt (bug 8022)
by Kirill K. Smirnov 12 Apr '07

12 Apr '07

Just some thoughts in hope they would help: There is special utility called 'mode' in Windows. I can select output locale: mode con cp prepare ... mode con cp select ... I think it would solve many problems if similiar tool will be implemented in wine. [bug #8022 comment #7] -- Kirill

1 0

Re: [5/5] D3D9: Add a test for the converted vertex decl
by Ivan Gyurdiev 12 Apr '07

12 Apr '07

Looks good, but this comment is misleading - s/"second"/"first". + /* The contents should correspond to the second conversion */ + VDECL_CHECK(compare_elements(result_decl1, test_elements1)); Also, I thought when Henri was testing this that the object kept changing between sequential Get() calls ? Did you mention something about a driver bug causing this ? Ivan

2 1

Re: mshtml #1: Change TRACE to FIXME in stubs.
by Michael Stefaniuc 12 Apr '07

12 Apr '07

Jacek Caban wrote: > <S-Insert> > --- > dlls/mshtml/htmlbody.c | 70 > ++++++++++++++++++++++++------------------------ > 1 files changed, 35 insertions(+), 35 deletions(-) > > > ------------------------------------------------------------------------ > > diff --git a/dlls/mshtml/htmlbody.c b/dlls/mshtml/htmlbody.c > index f8be550..542c989 100644 > --- a/dlls/mshtml/htmlbody.c > +++ b/dlls/mshtml/htmlbody.c > @@ -138,245 +138,245 @@ static HRESULT WINAPI HTMLBodyElement_Invoke(IHTMLBodyElement *iface, DISPID dis > static HRESULT WINAPI HTMLBodyElement_put_background(IHTMLBodyElement *iface, BSTR v) > { > HTMLBodyElement *This = HTMLBODY_THIS(iface); > - TRACE("(%p)->(%s)\n", This, debugstr_w(v)); > + FIXME("(%p)->(%s)\n", This, debugstr_w(v)); It should then include "Stub" in the FIXME message so people know why they get those. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

locales, unicode and ansi with msvcrt (bug 8022)
by Ann & Jason Edmeades 12 Apr '07

12 Apr '07

Hello, Bug 8022 (http://bugs.winehq.org/show_bug.cgi?id=8022) has highlighted something interesting which has me puzzled... Basically lets take xcopy as an example command line application. It issues messages to the screen using MSVCRT's wprintf(L"Unicode string") type function Wprintf -> vsnwprintf and builds a Unicode string to output. This ends up calling fwrite -> _write -> WriteFile -> WriteConsoleA Since an ANSI function gets called, the string gets converted into Unicode again (it was Unicode, so now ifs char with 3 0x00's!) and it comes out garbled. This garbage is only visible with e.g. "wineconsole --backend=user wine cmd /K xcopy", and non-wineconsole modes the extra 0x00's seem to do no harm, but they are there (try sending wine xcopy >a.a 2>&2 then vi a.a). So it looks like the problem is we shouldn't call fwrite from a Unicode msvcrt function. However, references like: http://groups.google.co.uk/group/comp.os.ms-windows.programmer.win32/browse_ thread/thread/6c0ecec3ad89d5b9/aa7a8c2085a12aa1?lnk=st&q=fwide+fwrite&rnum=1 0#aa7a8c2085a12aa1 seem to imply MSVCRT only outputs narrow characters. Now I am out of my depth... Should msvcrt be changed so all unicode functions convert to narrow before outputting anything - feels wrong. Ideally I could change the fwrites to WriteConsoleW's, but if the output should be to a file this is wrong. Is the solution to see if it's a console handle and call WriteConsoleW, and if not convert to narrow and then call fwrite, all within the msvcrt layer? Now I know there's much better people here than me who might be able to answer this, so all info welcome! The last of these will easily fit into msvcrt's tests, which I will do, but I'd also like to know how to approach a fix which I can do at the same time.... Jason PS Sample test program for compilation under windows (use /MD) - I can send an exe if anyone wants it... #include <windows.h> #include <stdio.h> void main() { WCHAR buffer[] = L"Hello Jason\n"; DWORD x; FILE *f; // Proves WriteFile outputs as-is WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), buffer, sizeof(buffer), &x, NULL); // Proves msvcrt converts to narrow (send output to file) - fails on wine wprintf(buffer); // File i/o has same problem? (Windows - narrow, Wine - includes nulls) f = _wfopen(L"test", L"w+t"); fwprintf(f, buffer); fclose(f); }

3 4

Wine vs. Cedega in Benchmarks
by Tom Wickline 12 Apr '07

12 Apr '07

Hello All, I have been pondering the thoughts of running every benchmark that I have on Wine, Cedega, XP, and CX to see where we stack up in the performance game. And while doing my daily reading of news sites I came across this posted on /. http://www.phoronix.com/scan.php?page=article&item=681&num=1 Those guys ran 5 game test and Wine's performance is clearly superior to that of Cedega on benchmarks where Wine was run, they give no details of the Wine configuration, So I can only presume it's a default setup. And since there *trying* to paint the best picture possible for Cedega they don't point out that Wine is superior! "It is also important to note that there were minimal performance differences between WINE 0.9.32 and Cedega 6.0. Granted there are only five benchmarks in this Cedega 6.0 performance preview, but the level of performance for Cedega does look extremely promising and we will continue to look at Cedega 6.0 and report back in future articles." Should read : Cedega's performance is currently lagging that of Wine 0.9.32 and with each Wine release Wine's performance and feature set is continuously improving! I'm open for thoughts and suggestions.... -- Tom Wickline Respectable computing - Linux/FOSS

5 11