- Wine-Devel - list.winehq.org

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

Copy / Paste with complex Objects
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 copy/paste functionality of Corel Draw on diffrent SuSE 10 Systems. On one system copy/paste works fine (without any failure) on a other system there is no function at all. (itss storage error). Can somebody tell me which system libraries used for the copy/paste functions? So that I can compare the two systems to find out where the copy/paste error cames from. Many thanks Roland Kaeser

1 0

Re: WINMM: prevent division by zero in mciwave
by Eric Pouech Feb. 14, 2006

Feb. 14, 2006

Alex Villacís Lasso wrote: > This was found while digging for the source of the mp3 jittering > problem. Both native L3CODECA.ACM and winemp3 trigger this > division-by-zero exception with ACMAPP.EXE demonstration program from > MSDN when using the Player! menu item with a MP3-encoded .WAV file > unless this patch is applied. > > Changelog: > > * Prevent division-by-zero exception on codecs that do not report > bits-per-sample. > > Alex Villacís Lasso > > > ------------------------------------------------------------------------ > > diff -ur wine-0.9.7-cvs/dlls/winmm/mciwave/mciwave.c wine-0.9.7-cvs-patch/dlls/winmm/mciwave/mciwave.c > --- wine-0.9.7-cvs/dlls/winmm/mciwave/mciwave.c 2005-12-06 16:28:17.000000000 -0500 > +++ wine-0.9.7-cvs-patch/dlls/winmm/mciwave/mciwave.c 2006-02-12 11:52:25.000000000 -0500 > @@ -205,7 +205,7 @@ > ret = val; > break; > case MCI_FORMAT_SAMPLES: /* FIXME: is this correct ? */ > - ret = (val * 8) / wmw->lpWaveFormat->wBitsPerSample; > + ret = (val * 8) / (wmw->lpWaveFormat->wBitsPerSample ? wmw->lpWaveFormat->wBitsPerSample : 1); > break; I think the overall fix is wrong. The computation is correct for PCM files, not for MP3 (and any other non linear compression format). You should check how native mciavi32 behaves here. A+ -- Eric Pouech

1 0

msvcrt: portable printf integer conversions
by Jesse Allen Feb. 14, 2006

Feb. 14, 2006

I've been trying to get some functionality to the %I64 printf size specifier. My last patch was rejected because it was non-portible. Therefore, I've written an internal function, pf_integer_conv, to handle the conversion of integers only -- not floats. The patch tries to not impact the current printf infrastructure as much as possible, therefore it only forwards %I64 sizes. However, it could be possible to foward all integer types as I wrote it to handle them all, and this is probably the way to go. There are a couple of problems I have discovered in our printf. One is that if flags->Precision is zero, then it is unused. But according to man 3 printf, precision can be explicitly defined as zero. Therefore, we do not handle "zero" precision. The next problem is when we rebuild our format string to handle the integer and floats, and call printf from libc to handle it. It happens to print to a fixed buffer of 40 without checking. If we ever get called to print a number with a field length greater than 40 or whatever large combination, libc will happily print beyond the end of the buffer. These are problems in the current infrastructure and will need to be addressed. Any comments? I'd like to have a better idea on restructuring the printf to handle number conversions before we move forward. I still need to work on floating point too, as of yet. Jesse

1 1

Re: usp10: [RESEND] Add ScriptItemize, ScriptShape and ScriptPlace functionality
by James Hawkins Feb. 14, 2006

Feb. 14, 2006

On 2/13/06, Jeff L <lats(a)yless4u.com.au> wrote: > This patch is a resend that contains the correct file that combines the > code and the tests, sent previously as two patches, into one patch. It > also has the .cvsignore for dlls/usp10/tests and fixes some issues with > comments and dead code. > You'll have more luck getting this accepted if you send each function implementation in separate patches. Some comments about the patch: if (psc) *psc = NULL; return 0; + HeapFree ( GetProcessHeap(), 0, *psc); + *psc = NULL; You should keep the if (psc), because the user can send in a NULL psc. - FIXME("%p,%p\n",ppSp,piNumScripts); + FIXME("%p,%p,%p\n",ppSp, *ppSp, piNumScripts); If this function is now implemented, it should be a TRACE and not a FIXME. If ppSp is NULL, this call to FIXME will cause a crash (see next comment.) - if (piNumScripts) *piNumScripts = 0; +/* Set up a sensible default and intialise pointers */ + *piNumScripts = MAX_SCRIPTS; + *ppSp = (SCRIPT_PROPERTIES *)Global_Script; Same as above, need to keep the if (ptr) checks. + TRACE("ppSp:%p, *ppSp:%p, **ppSp:%p, %d\n", ppSp, *ppSp, **ppSp, + *piNumScripts); If you *really* need to see all the values of these pointers, then you have to check that each pointer above it is not NULL. + FIXME("(%p,%p,%p,%s,%d,%d, %p, %d, %p, %d): stub\n", hdc, psc, pwcChars, I dont know what this function is supposed to do, but it looks like you've added quite a bit of functionality to this function. If it's not completely implemented, I would change it to semi-stub, so we know it at least does something. Same thing for the rest of the functions. A good first step is to send the tests in the first patch, adding todo_wine's where appropriate. Next send each function implementation in separate patches afterwards, removing todo_wine's from tests that now pass. -- James Hawkins

1 0

Re: user: Fix return type of GetDlgItemText{A,W}
by Troy Rollo Feb. 14, 2006

Feb. 14, 2006

On Tuesday 14 February 2006 11:59, Troy Rollo wrote: > ChangeLog: > user: Fix return type of GetDlgItemText{A,W} Please disregard this one - the argument types are wrong too. I will follow up with a consolidated patch fixing both -- Troy Rollo - wine(a)troy.rollo.name

1 0

Re: StretchDIBits function problem.
by Cyril Margorin Feb. 13, 2006

Feb. 13, 2006

Hello, According the patches, I've send before: I've got two small questions: 1) Shouldn't the Shared Memory XImage created in X11DRV_DIB_SetImageBits/X11DRV_DIB_GetImageBits functions? Or creating shared memory image takes too long? 2) Shouldn't XImage be passed to X11DRV_DIB_SetImageBits, and useShm field correctly in X11DRV_SetDIBits? Why it was NULL in X11DRV_GetDIBits and is NULL in X11DRV_SetDIBits, with useShm hardcoded to FALSE? -- Cyril Margorin

1 0