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

Wine and Font-Rendering, copy/paste (partial solution)
by Roland Kaser Feb. 15, 2006

Feb. 15, 2006

Hello As seen on My previous post about copy/paste and font rendering, both functions does work on some systems but not on other. I made some test installations with SuSE 10 and wine 0.9.7 (the rpm version form Marcus) and found a partial solution: It seems that the font-rendering and copy/paste works on SuSE 10 (original installed system, without and SuSE online update). As soon the first SuSE Online Update was made, the font-rendering and copy/paste refuses to work. I'm currently not sure whats the exact reason for this behaviour. Does eventually somebody has close contacts to the SuSE developers and can discuss it with them? The Error is definitively reproducable on diffrent hardware types. Kind regards Roland Kaeser

1 0

Re: [RESENT] Don't duplicate handles for _get_osfhandle
by Alexandre Julliard Feb. 15, 2006

Feb. 15, 2006

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > wine/dlls/msvcrt/file.c: _get_osfhandle > Don't duplicate handles, otherwise they leak > > This time with test case that fails without the patch (but succeed with > native msvcrt). It would be nice to also add a test for the case that the DuplicateHandle was supposed to fix, so that we can avoid reintroducing that bug. -- Alexandre Julliard julliard(a)winehq.org

2 1

Startup time of OOo2, Firefox 1.5. Some surprises.
by Dan Kegel Feb. 15, 2006

Feb. 15, 2006

To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM (by booting with mem=96M; this was to simulate running on one of those cheapo 128MB boxes that uses shared video RAM). This was on a zippy Compaq Presario 3000 Athlon 64 3000+. All apps were downloaded from openoffice.org and mozilla.com. Results for first run of app after booting (1st column is startup time): 5 Firefox run1 native 416MB 12 Firefox run1 wine 416MB 11 Firefox run1 native 96MB 15 Firefox run1 wine 96MB 11 ooo run1 native 416MB 15 ooo run1 wine 416MB 60 ooo run1 native 96MB 37 ooo run1 wine 96MB So wine is 1.4 to 2.5 times slower at app startup generally, but when ram is really short, win32 openoffice starts up with wine 1.5 times *faster* than the native linux version! (Maybe because the Microsoft tools are better at avoiding I/O or relocations during loading?) I then measured how long it took to start up the app the second time, when the cache was nice and hot: 3 Firefox run2 native 416MB 4 Firefox run2 wine 416MB 4 ooo run2 native 416MB 6 ooo run2 wine 416MB 4 Firefox run2 native 96MB 6 Firefox run2 wine 96MB 36 ooo run2 native 96MB 28 ooo run2 wine 96MB The times are uniformly faster on the second run, but the patter holds, i.e. wine is 1.4-1.5 times slower than native generally, but win32 openoffice under wine is 1.5 times *faster* than the native version when starved for RAM. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 12

[d3d8] question about "bogus" code
by Christoph Frick Feb. 15, 2006

Feb. 15, 2006

hiho as with newer versions more and more games i try no longer work (which worked with wine around 0.9.0) i try to find the reasons. i stumbled over this code in dlls/d3d8/surface.c: date: 2006-02-14 17:05:35 +0000; author: julliard; state: Exp; lines: +202 -319 Roderick Colenbrander <thunderbird2k(a)gmx.net> d3d8: Move d3d8 surface over to wined3d (based on the work of Oliver Stieber). 149 1.48 (julliard 14-Feb-06): if (This == D3D8_SURFACE_GET_DEVICE(This)->backBuffer || This == D3D8_SURFACE_GET_DEVICE(This)->renderTarget || This == D3D8_SURFACE_GET_DEVICE(This)->frontBuffer || D3D8_SURFACE_GET_DEVICE(This)->depthStencilBuffer) { 150 1.48 (julliard 14-Feb-06): if (This == D3D8_SURFACE_GET_DEVICE(This)->backBuffer) { 151 1.48 (julliard 14-Feb-06): TRACE("(%p, backBuffer) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 152 1.48 (julliard 14-Feb-06): } else if (This == D3D8_SURFACE_GET_DEVICE(This)->frontBuffer) { 153 1.48 (julliard 14-Feb-06): TRACE("(%p, frontBuffer) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 154 1.48 (julliard 14-Feb-06): } else if (This == D3D8_SURFACE_GET_DEVICE(This)->renderTarget) { 155 1.48 (julliard 14-Feb-06): TRACE("(%p, renderTarget) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 156 1.48 (julliard 14-Feb-06): } else if (This == D3D8_SURFACE_GET_DEVICE(This)->depthStencilBuffer) { 157 1.48 (julliard 14-Feb-06): TRACE("(%p, stencilBuffer) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 158 1.9 (julliard 17-May-03): } 159 1.9 (julliard 17-May-03): } else { 160 1.48 (julliard 14-Feb-06): TRACE("(%p) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 161 1.9 (julliard 17-May-03): } why is in line 149 for the depthStencilBuffer check not comparing against This like in three checks before? if there is a reason, if would be good to have a comment there - otherwise it looks like an error. -- cu

4 3

DSOUND bugs
by Tomas Carnecky Feb. 15, 2006

Feb. 15, 2006

I'm really wondering why nobody has fixed the DSOUND buffer underrun bugs.. I get lots of these message when I run World of Warcraft: err:wave:wodPlayer_ProcessMessages pcm_pause failed: Input/output error err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fda2038 I can fix these buffer underruns partially by playing with the buffer size in asoundrc, but it never disappears completely. It gets worse if I also start TeamSpeak (which btw. uses 50% of the CPU)), but I can play videos using totem or mplayer or listen to music without any xruns. is it really unknown where the bug is? because I'm willing to test patches and helm looking where the bug might be.. tom

3 5

crosstool-0.40 status 2
by Dan Kegel Feb. 15, 2006

Feb. 15, 2006

Since I'm developing on ubuntu, where the default compiler is gcc-4.0.x, I'm running into a lot of little problems (glibc-2.3.2 unhappy about gcc-4.0 during initial header installation, binutils-2.15 incomplete array type errors). Fortunately, having waited forever to do this update, googling for the errors is turning up proposed fixes. I've also included a few of the cygwin and mac doc fixes and one or two other little fixes people have contributed. I should have something for people to play with in a day or so. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 1

Wine Font Rendering
by Roland Kaser Feb. 14, 2006

Feb. 14, 2006

Hello Sorry, this is the second post for this reason, but it's important for me to sort this problem out. Can somebody try to get a answer? I noticed a strange behavior of the Font/Vector objects functionality of Corel Draw on diffrent SuSE 10 Systems. On one system Rotated Text works fine (without any failure) on a other system, rotated fonts became invisible on the screen. At pdf export, the fonts are normally visible. So it seems to be a graphics subsystem error. No winedebug output at all. Can somebody tell me which system libraries used for the font rendering functions? So that I can compare the two systems to find out where the font-rendering error cames from. Many thanks Roland Kaeser

4 3

Re: Appdb thoughts
by Chris Morgan Feb. 14, 2006

Feb. 14, 2006

> Unfortunately, I'm not volunteering since I know nothing about the codebase > for either project, but it is really just a matter of creating a new table > and adding a field or two to the existing tables (and updating the > interface, of course). Its written in php and the source is available through cvs if you are interested in taking a look. We can always use help. Chris

1 0

Refcounting fun
by H. Verbeet Feb. 14, 2006

Feb. 14, 2006

I've run into a somewhat annoying problem with d3d9/wined3d recently. It appears that on d3d9 on Windows a surface either forwards its AddRef / Release calls to its container if it has one, or just shares the refcount directly. Either way, it comes down to the same thing. Calling AddRef on the surface increases the texture's refcount and calling AddRef on the texture increases the surface's refcount. Same thing for Release. As a consequence, on Windows, it's perfectly legal to do something like this: /* Create a texture */ IDirect3DDevice9_CreateTexture() /* Get a surface. Adds a reference to the surface/texture combination */ IDirect3DTexture9_GetSurfaceLevel() /* Release the texture. Note that the texture isn't freed yet, because we still hold a reference to the surface */ IDirect3DTexture9_Release() <Do some stuff with the surface, perhaps call GetContainer, etc> /* Release the surface. The texture and all of it's surfaces will now be released. */ IDirect3DSurface9_Release() In wine, the call to IDirect3DTexture9_Release() frees the texture. (It also calls Release on it's surfaces, but since the surface had an extra reference from the call to GetSurfaceLevel the surface is still ok). Calling any function on the surface that needs access to the container will now have undefines results, most likely a crash. Naively, I tried to fix this by having the surface keep a reference to it's container. That keeps the code above from crashing, but only because it creates a circular reference between the surface and the container. Oops. Fixing the problem for wined3d is probably not even that hard. Just separate the Release code from the Cleanup code, then have WineD3DSurface forward its AddRef / Release calls to the container, if it has one. The container can then call the Cleanup code for its surfaces when it gets deleted. However, there is another problem, related to the way d3d9 (and ddraw/d3d7/d3d8, when their respective rewrites are finished) wraps wined3d. After fixing the problem for wined3d as above, the relation between IDirect3DSurface9 and IDirect3DTexture9 in wine would look roughly like this: |-------------------| |-------------------| | IDirect3DSurface9 | | IDirect3DTexture9 | |-------------------| |-------------------| ^ ^ | | |----------------| |----------------| | WineD3DSurface |<--------->| WineD3DTexture | |----------------| |----------------| WineD3DSurface and WineD3DTexture "share" reference counts, IDirect3DSurface9 keeps a reference to WineD3DSurface, and IDirect3DTexture keeps a reference to WineD3DTexture. WineD3DSurface and WineD3DTexture don't keep references to their parents (and can't, without creating circular references). So releasing the texture before the surface would still not work, since the d3d9 texture still has only 1 reference, the one it got when it was created. That means that in the call to IDirect3DTexture9_Release the d3d9 texture gets freed, while the wined3d texture doesn't. When we do something with the d3d9 surface that needs the container, the wined3d surface correctly returns its container, but when d3d9 then tries to get the parent of that container it still dies. One way to solve this would be to have wined3d handle the reference counting for d3d7/8/9 as well, so that their AddRef/Release calls just call AddRef/Release on the wined3d object they wrap. That would also mean we need to pass a pointer to the d3d7/8/9 object's cleanup function. (Releasing a d3d9 surface to 0 should cause a d3d9 texture to be freed). Note that for creating a texture, currently a similair construction is used, in that IWineD3DDeviceImpl_CreateTexture gets passed a pointer to a d3d9 surface create function, in order to create the texture's surfaces. Obviously doing all that would be quite a change in the way d3d is setup in wine, and would also have some implications for the d3d7 and d3d8 rewrites. I'm wondering if this solution would be acceptable, and whether perhaps there are other, better solutions. Anyone care to comment?

2 14

WINEMP3: increase factor from 4 to 12 in MPEG3_StreamSize
by Alex Villacís Lasso Feb. 14, 2006

Feb. 14, 2006

This is a summary of what I have been doing with winemp3 over the weekend. First, the idea of a GStreamer wrapper for wine is a no-go because 1) would not solve the jittering problem (more on this later), 2) I have not found yet a streaming source for raw memory buffers (as opposed to file/network streaming), 3) although GStreamer is LGPL, some of the codecs might be proprietary, and this might cause legal problems later on. I fired the ACMAPP.EXE demo program from MSDN (the one I used to improve the msacm implementation), and noticed that MP3-encoded WAV files play almost normally with this app. This means that the codec itself is not the problem - the most likely source is the (odd?) use of msacm by dsound, which is in turn invoked by native quartz.dll. Before reaching this conclusion, I found that ACMAPP.EXE played the files without jittering, but it stopped playing a few moments before the end of the song. How much before depends on the actual length of the song but this was annoying enough to be worth investigating. For example, one sample song stopped playing 30 seconds before the actual end. However, according to the app, playback was already at the end of the song. It turns out that mpglib has a queue of undecoded data in its decoding structure. On every call to the decodeMP3() function of mpglib, the caller specifies either a buffer of new data, or NULL to use the remaining data from a previous invocation. The buffer grows and shrinks dynamically with the amount of unencoded data passed by the caller. What was going on was the following: - Caller (winmm) computes required output buffer for encoded input buffer. This uses acmStreamSize, which in turn invokes MPEG3_StreamSize. - MPEG3_StreamSize return a factor 4X for the size of the output buffer (in my tests, a 2333-byte encoded buffer expands into (at most) 9332 bytes of output, or so reports winemp3). - winmm happily calls acmStreamConvert() with a 2333 source buffer and a 9332 destination buffer. - mpglib decodes as much as it can into the 9332-byte buffer. However, in almost all cases, 9332 bytes is not enough to decode 2333 bytes of MP3 data. This is important to note, because it means a non-trivial amount of the MP3 data remains in the mpglib queue. - acmStreamConvert() is called over and over, with a 2333 source buffer and a 9332 destination buffer. The output buffer is always too small, so the undecoded data in the mpglib buffers accumulates. - winmm sends the last encoded buffer. Supposedly this means that decoding is complete, but it isn't, because mpglib has a backlog of undecoded data which has not been played. However, winmm stops there, and the user notices the cut in the middle of the song. In the same situation, L3CODECA.ACM reports a non-integer factor for the output buffer, a little under 12X. Therefore L3CODECA.ACM always has enough space to consume the full source buffer and therefore does not cut the song in the middle. The ideal solution would be to dynamically compute the expansion factor based on the input and output bitrates. The attached patch raises the expansion factor instead to 12X to ensure that mpglib can always decode all the input data without running out of output space. Changelog: * Increase size factor from 4 to 12 in MPEG_StreamSize, otherwise mpglib buffer queue grows * Add TRACE of mpglib buffer queue for conversion. Alex Villacís Lasso

2 1