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

Re: x11drv fix for bug#4506: page fault on read access

by Rein Klazes

On Tue, 28 Feb 2006 12:38:13 +0100, you wrote: >This will badly hurt performance, you don't want to check alignment on >every pixel. You should only check on the first one and copy 1 to 3 >pixels as needed to align things properly, then do the 4 pixels at a >time thing. Yes, it was rather optimized for small code ;-) Here is the result following your suggestion. Changelog: dlls/x11drv : dib_convert.c Avoid unaligned 32 bit reads, and reads beyond the input pixel buffer in the convert_888_to_0888_* functions. Rein.

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Aric Cyr

Stefan Dösinger <stefandoesinger <at> gmx.at> writes: > > > If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help. > > We could set up a time to chat/irc off-list or if you want I could see if > > I can get your existing stuff to work (just send me the diffs). > I'll publish a patch in the next days, I just want to fix S3TC decompression > and perhaps get my hands on Diablo 2. I own Diablo 2... this would be a good reason to dust it off :) > The problem I have with GL ATM is UnlockRect. The current code in > WineD3DSurface::UnlockRect doesn't work with a lot of cards / drivers(radeon, > fglrx and mesa software rendering fail). glReadPixels and glWritePixels is > horribly slow on radeons, it takes 1-4 secounds for an 800x600 image. I am running fglrx as well, so I could work on getting the performance up on these cards. I also have contacts at ATI, so if there are specific problem I could send feedback directly, and hopefully they can fix things for future releases. Although I'd check glDrawPixels on Windows as well... I suspect it is just as slow there. Also for glDrawPixels you should turn off a lot of the GL state (lighting and stuff that you don't need). That could speed things up a bit. > So what I need is an UnlockRect code for render targets that doesn't use > glDrawPixels. I have written a code that replaces ReadPixels with copying the > render target to a texture and reading back the texture, this works much > better. I tried to write an UnlockRect code that loads a temporary texture > and Draws a textured quad, but the quad had the solid color of the first > pixel. Sounds like it shouldn't be too difficult OpenGL problem. There are a lot of commands related to texturing, so it is quite easy to muck things up. I looked at the code a bit that you posted before, but nothing jumped out at me, although it would be easier if I had the full code to play with. > Thanks for your help :) No problem, anything that will help accelerate the merge of ddraw/d3d7 into wined3d :) Regards, Aric

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Mike Hearn

On Fri, 24 Feb 2006 21:11:39 +0300, Vitaly Lipatov wrote: > Sorry for my English. It is useful when we run wine from the source tree. It's useful for people distributing Wine binaries as well. Not every feature is there for the distros you know ... also asking developers to disable rpath because RPM cannot cope with it is remarkably poor form IMO, just fix RPM!

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Stefan Dösinger

> If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help. > We could set up a time to chat/irc off-list or if you want I could see if > I can get your existing stuff to work (just send me the diffs). I'll publish a patch in the next days, I just want to fix S3TC decompression and perhaps get my hands on Diablo 2. The problem I have with GL ATM is UnlockRect. The current code in WineD3DSurface::UnlockRect doesn't work with a lot of cards / drivers(radeon, fglrx and mesa software rendering fail). glReadPixels and glWritePixels is horribly slow on radeons, it takes 1-4 secounds for an 800x600 image. So what I need is an UnlockRect code for render targets that doesn't use glDrawPixels. I have written a code that replaces ReadPixels with copying the render target to a texture and reading back the texture, this works much better. I tried to write an UnlockRect code that loads a temporary texture and Draws a textured quad, but the quad had the solid color of the first pixel. Thanks for your help :) Stefan

March 1, 2006

Re: wined3d: Fix compile for older OpenGL headers.

by Vitaly Budovski

H. Verbeet wrote: > Although #ifdef GL_VERSION_2_0 will make compilation work with older > OpenGl headers, it's not the way to fix this. Basically, wined3d > should check for functionallity during runtime with GL_SUPPORT and > call extensions with GL_EXTCALL. The issue has come up a few times > before with patches from the same author, and I think he should be > aware of the issue by now. > > That takes care of functions as part of an OpenGL extension. What about core functions of a newer GL version? Would all of those need to be defined in the wined3d_gl.h file?

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Aric Cyr

Stefan Dösinger <stefandoesinger <at> gmx.at> writes: > > > Hi. I've been dealing with a program that seems to be very slow at > > Blitting images onto a D3D surface. Unfortunately, this is not my code > > so I can't fix it. Would the above mentioned BltFast/CopyRect patches > > deal with code that attempts to provide this feature? > Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty > slow on that cards. BltFast won't fix that, it needs a better UnlockRect > implementation in WineD3D. I tried to do that, but I failed because of a lack > of gl knowledge, but I'll make another attempt sooner or later? If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help. We could set up a time to chat/irc off-list or if you want I could see if I can get your existing stuff to work (just send me the diffs). Regards, Aric

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Stefan Dösinger

Hi, > For those intested here is a quick patch against dlls/wined3d/utils.c, I'll > submit an "official" one to wine-patches later, in the meantime feedback is > appreciated. I planned sending a similar patch which looked quite the same, but I'll let you do this.

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Stefan Dösinger

Hi, > Its actually an i865 and "must remain" an i865. Its amazing, the 3D > performance (with shadows and all) is pretty fast if I disable the code > that results in the screen blits. I have never used an Intel chip, so I can't judge about it's speed. > If you'd like, I'd be willing to help out if I can on getting this > working better. Sounds like you've gotten a head start on it. I'm quite busy now with finishing my ddraw patch, but when that is in and the regressions are out, I'll ask for apps that aren't working as they should, and then I can look at it. Except, if you desperatly need this blits working, I can have a quick look at it.

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Aric Cyr

Raphael <fenix <at> club-internet.fr> writes: > But we must fix all the RGB v.s. BGR problems I'll submit a patch for this when I get home. I verified it with Age of Mythology and the latest CVS (well, from a few days ago). There are just a couple of mistakes in d3d8/utils.c (whoops this file is gone now, great!) and wined3d/utils.c that need fixing, although I don't know if my patch covers all cases, it certainly works for RGB888, RGB565, RGB332 (8bpp rgb). For those intested here is a quick patch against dlls/wined3d/utils.c, I'll submit an "official" one to wine-patches later, in the meantime feedback is appreciated. --- dlls/wined3d/utils.c.orig 2006-03-01 19:09:08.000000000 +0900 +++ dlls/wined3d/utils.c 2006-03-01 19:09:32.000000000 +0900 @@ -1703,9 +1703,9 @@ case WINED3DFMT_Q8W8V8U8: retVal = GL_RGBA; break; case WINED3DFMT_Q16W16V16U16: retVal = GL_COLOR_INDEX; break; /* color buffer */ - case WINED3DFMT_R3G3B2: retVal = GL_BGR; break; - case WINED3DFMT_R5G6B5: retVal = GL_BGR; break; - case WINED3DFMT_R8G8B8: retVal = GL_BGR; break; + case WINED3DFMT_R3G3B2: retVal = GL_RGB; break; + case WINED3DFMT_R5G6B5: retVal = GL_RGB; break; + case WINED3DFMT_R8G8B8: retVal = GL_RGB; break; case WINED3DFMT_A1R5G5B5: retVal = GL_BGRA; break; case WINED3DFMT_X1R5G5B5: retVal = GL_BGRA; break; case WINED3DFMT_A4R4G4B4: retVal = GL_BGRA; break; Regards, Aric

March 1, 2006

Re: [PATCH 1/4] [WineDbg]: main_loop

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > - split dbg_main_loop in two parts (one for finishing the debuggee > attachment, the second one really for handling the main loop) > - removed now longer needed dbg_main_loop Auto mode is still broken with this patch... did you really test it? -- Alexandre Julliard julliard(a)winehq.org

March 1, 2006

Re: EaseReader gives fixme:amstream:IAMMultiMediaStreamImpl_Initialize

by Peter Åstrand

On Thu, 26 Jan 2006, Peter Åstrand wrote: > Hi. I'm trying to get the EaseReader application > (http://www.dolphinaudiopublishing.com/products/EaseReader/) running in Wine. > By using the native oleacc, oleaut32 and rpcrt4, it's now actually possible > to start the application. The "self voicing" mode also works: The application > "speaks", for example when hovering above menu choices. Listening to the > actual DAISY book does not work, however. I get: > > fixme:imm:ImmGetContext (0x10136): stub > fixme:imm:ImmGetContext (0x10136): stub > fixme:amstream:IAMMultiMediaStreamImpl_QueryInterface (0x7a4fdc50/0x7a4fdc50)->({bebe595c-9a6f-11d0-8fde-00c04fd9189d},0x7fc6e968) > fixme:amstream:IAMMultiMediaStreamImpl_Initialize (0x7a4fdc50/0x7a4fdc50)->(0,1,(nil)) partial stub! > fixme:amstream:IAMMultiMediaStreamImpl_AddMediaStream (0x7a4fdc50/0x7a4fdc50)->((nil),0x4b0d3200,0,(nil)) partial stub! > fixme:amstream:IAMMultiMediaStreamImpl_OpenFile (0x7a4fdc50/0x7a4fdc50)->(L"c:\\program files\\easereader demo\\help\\22_highlig.mp3",8) stub! It seems like the main problem is the IAMMultiMediaStreamImpl_OpenFile stub. I've tried a quick-n-dirty hack: Just calling ShellExecute from IAMMultiMediaStreamImpl_OpenFile. See the patch below. After installing Winamp, this actually works (but stop/seek etc doesn't work, of course). So: Now I'm wondering: How difficult would it be to properly implement IAMMultiMediaStreamImpl_OpenFile? Best Regards, Peter Åstrand diff -u -r1.12 amstream.c --- amstream.c 7 Nov 2005 16:38:48 -0000 1.12 +++ amstream.c 1 Mar 2006 09:45:06 -0000 @@ -28,6 +28,7 @@ #include "winbase.h" #include "wingdi.h" +#include "shellapi.h" #include "amstream_private.h" #include "amstream.h" @@ -284,6 +285,12 @@ FIXME("(%p/%p)->(%s,%lx) stub!\n", This, iface, debugstr_w(pszFileName), dwFlags); + if (dwFlags & AMMSF_RUN) { + static const WCHAR verbW[] = {'o', 'p', 'e', 'n', 0}; + ShellExecuteW(NULL, verbW, pszFileName, NULL, NULL, SW_SHOWNORMAL); + return S_OK; + } + return E_NOTIMPL; } -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

March 1, 2006

Re: riched20: EM_AUTOURLDETECT/EM_GETAUTOURLDETECT implementation

by Alexandre Julliard

Brandon Woodmansee <bwood(a)ucla.edu> writes: > + case EM_AUTOURLDETECT: > + { > + if (wParam==1) > + { > + editor->AutoURLDetect_bEnable=1; > + return 0; > + } > + > + if (wParam==0) > + { > + editor->AutoURLDetect_bEnable=0; > + return 0; > + } > + return E_INVALIDARG; E_INVALIDARG is a pretty strange return value for a window procedure. Do you have a test case for that? -- Alexandre Julliard julliard(a)winehq.org

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Coleman Kane

Its actually an i865 and "must remain" an i865. Its amazing, the 3D performance (with shadows and all) is pretty fast if I disable the code that results in the screen blits. It looks like it may actually be running them through some "Stretch Blit" function. I don't know if this might translate down to a D3D call or not that does a size transform at the time of Blit. If you'd like, I'd be willing to help out if I can on getting this working better. Sounds like you've gotten a head start on it. -- Coleman Kane IntelliTree Solutions llc. On Wed, 2006-03-01 at 09:05 +0100, Stefan Dösinger wrote: > > Hi. I've been dealing with a program that seems to be very slow at > > Blitting images onto a D3D surface. Unfortunately, this is not my code > > so I can't fix it. Would the above mentioned BltFast/CopyRect patches > > deal with code that attempts to provide this feature? > Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty > slow on that cards. BltFast won't fix that, it needs a better UnlockRect > implementation in WineD3D. I tried to do that, but I failed because of a lack > of gl knowledge, but I'll make another attempt sooner or later?

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Stefan Dösinger

> Hi. I've been dealing with a program that seems to be very slow at > Blitting images onto a D3D surface. Unfortunately, this is not my code > so I can't fix it. Would the above mentioned BltFast/CopyRect patches > deal with code that attempts to provide this feature? Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty slow on that cards. BltFast won't fix that, it needs a better UnlockRect implementation in WineD3D. I tried to do that, but I failed because of a lack of gl knowledge, but I'll make another attempt sooner or later?

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Raphael

On Wednesday 01 March 2006 05:48, Al Tobey wrote: > I just tried the new d3d8 code with FFXiBench3 again tonight and it's > pretty good! The textures are mostly there and there are only a > handful of recurring glitches. This demo is downloadable from > http://www.playonline.com. > > Some textures had their colors munged up. I assume this is related > to earlier discussions about RGB_ v.s. BGR_ formats. > Screenshots: > http://img238.imageshack.us/img238/9879/screenshot28hh.jpg > http://img48.imageshack.us/img48/4135/screenshot35wa.jpg > http://img48.imageshack.us/img48/28/screenshot48xx.jpg > > I got a lot of these two messages: > fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking > to Rendering surface surf(a)0x7d388550 usage(1) > fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces > not implemented, returning D3DERR_INVALIDCALL > > I'll play around with my CopyRects patch a bit and see if I can get it > to work properly then submit it. I'm not convinced MSDN is telling > the whole truth about how partial copies should work. > > Keep up the good work! > -Al Tobey Good news :) Seems working correctly But we must fix all the RGB v.s. BGR problems Best Regards, Raphael

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Coleman Kane

On Wed, 2006-03-01 at 07:50 +0100, Stefan Dösinger wrote: > Hi, > > I got a lot of these two messages: > > fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking > > to Rendering surface surf(a)0x7d388550 usage(1) > > fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces > > not implemented, returning D3DERR_INVALIDCALL > > > > I'll play around with my CopyRects patch a bit and see if I can get it > > to work properly then submit it. I'm not convinced MSDN is telling > > the whole truth about how partial copies should work. > This CopyRect functionality could be implemented using > IWineD3DSurface::BltFast, once my DirectDraw patches are in. Hi. I've been dealing with a program that seems to be very slow at Blitting images onto a D3D surface. Unfortunately, this is not my code so I can't fix it. Would the above mentioned BltFast/CopyRect patches deal with code that attempts to provide this feature? -- Coleman Kane IntelliTree Solutions llc.

March 1, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Stefan Dösinger

Hi, > I got a lot of these two messages: > fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking > to Rendering surface surf(a)0x7d388550 usage(1) > fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces > not implemented, returning D3DERR_INVALIDCALL > > I'll play around with my CopyRects patch a bit and see if I can get it > to work properly then submit it. I'm not convinced MSDN is telling > the whole truth about how partial copies should work. This CopyRect functionality could be implemented using IWineD3DSurface::BltFast, once my DirectDraw patches are in.

March 1, 2006

PATCH: updated PACKAGING (Re: libxml2 use in Wine?)

by Marcus Meissner

On Tue, Feb 28, 2006 at 11:19:19PM +0100, Gerald Pfeifer wrote: > On Tue, 28 Feb 2006, Raphael wrote: > > Yes wine use libxml2 for msxml implementation (see > > dlls/msxml3/Makefile.in) but autoconf/automake check it > > Thanks for this information. Alexandre, patch for you below. ;-) > > Gerald > > ChangeLog: > Fix spelling Red Hat. Remove unneeded references to Debian and > Red Hat. Document the use of libxml2 as a weak prerequisite. Also add it to PACKAGING, plus some more. Ciao, Marcus Changelog: Mention more libraries / tools in the needed dependencies section. Index: documentation/PACKAGING =================================================================== RCS file: /home/wine/wine/documentation/PACKAGING,v retrieving revision 1.19 diff -u -r1.19 PACKAGING --- documentation/PACKAGING 6 Jan 2006 20:50:33 -0000 1.19 +++ documentation/PACKAGING 1 Mar 2006 06:09:39 -0000 @@ -64,6 +64,9 @@ better support of fonts than using the X11 fonts engine. It is only needed for the X11 back end engine. Used from GDI. + * fontforge: http://sourceforge.net/projects/fontforge/ + Used by WINE to create our own set of TrueType fonts during build. + * fontconfig Used to find TrueType fonts for rendering with freetype. Used by GDI. @@ -119,6 +122,15 @@ Xi - X Input handling (for asian input methods mostly) Xext - X extensions + * libxml2, libxslt + These two libraries are used for our msxml3.dll implementation. + + * prelink + Used during build to locate WINE at a specific virtual address. + + * capi4linux + Used to implement our capi2032.dll. + GOALS ~~~~~

March 1, 2006

New d3d8 code and FFXIBench3 - pretty good!

by Al Tobey

I just tried the new d3d8 code with FFXiBench3 again tonight and it's pretty good! The textures are mostly there and there are only a handful of recurring glitches. This demo is downloadable from http://www.playonline.com. Some textures had their colors munged up. I assume this is related to earlier discussions about RGB_ v.s. BGR_ formats. Screenshots: http://img238.imageshack.us/img238/9879/screenshot28hh.jpg http://img48.imageshack.us/img48/4135/screenshot35wa.jpg http://img48.imageshack.us/img48/28/screenshot48xx.jpg I got a lot of these two messages: fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to Rendering surface surf(a)0x7d388550 usage(1) fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces not implemented, returning D3DERR_INVALIDCALL I'll play around with my CopyRects patch a bit and see if I can get it to work properly then submit it. I'm not convinced MSDN is telling the whole truth about how partial copies should work. Keep up the good work! -Al Tobey

Feb. 28, 2006