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

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)

by Henri Verbeet

On 29 February 2012 13:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Fine with me, just don't blame me that those bugs aren't fixed :-) Yeah well, 27600 was reported in June last year.

Feb. 29, 2012

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)

by Stefan Dösinger

Am Mittwoch, 29. Februar 2012, 11:54:11 schrieb Henri Verbeet: > I guess I didn't explicitly say it yesterday, but I think this should > be deferred and fixed properly after 1.4. While in principle dropping > VBOs might be ok as a temporary fix for the release, the vertex / > index buffer code is pretty fragile in general, and I can't guarantee > that this won't introduce more regressions than it fixes. Fine with me, just don't blame me that those bugs aren't fixed :-)

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Maarten Lankhorst

Hey Chris, Op 29-02-12 06:58, Chris Robinson schreef: > On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote: >> + * This is basically the same as the pa_threaded_mainloop implementation, >> + * but that cannot be used because it uses pthread_create directly >> + * >> + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock >> + * pa_threaded_mainloop_signal -> pthread_cond_signal >> + * pa_threaded_mainloop_wait -> pthread_cond_wait > I'm curious why you're using pthreads. Doesn't WinAPI have anything comparable > to pthread_cond_wait? I'm literally following the pulseaudio mainloop here. If you look at their definitions they will map to those. Pulseaudio library on win32 was having their own weird version of pthread_cond_* which would go through wineserver multiple times for each signalling. The extra context switches would have been a sure way to kill any hope of efficiency and decreased the chances of the scheduler doing things right. :) pulseaudio/src/pulsecore/mutex-win32.c for reference >> +static void pulse_probe_settings(void) { > ... >> + ret = pa_stream_connect_playback(stream, NULL, &attr, >> + PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_FORMAT|PA_S >> TREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS, NULL, NULL); > Is it necessary to fix the format? MSDN says that the audio service always > works with floating-point, and GetMixFormat always specified floating-point in > my dealings with it. I don't think it should blindly return whatever > PulseAudio does, unless it can be shown that Windows doesn't always give > floating-point. I'd have to recheck on my windows pc, to see if that's the case. However if it is I don't see a problem with always specifying float and removing the fix flag for it. >> +static WAVEFORMATEX *clone_format(const WAVEFORMATEX *fmt) >> +{ >> + WAVEFORMATEX *ret; >> + size_t size; >> + >> + if (fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE) >> + size = sizeof(WAVEFORMATEXTENSIBLE); >> + else >> + size = sizeof(WAVEFORMATEX); >> + >> + ret = HeapAlloc(GetProcessHeap(), 0, size); > This should probably use CoTaskMemAlloc, as it's used for IsFormatSupported. > I'm also curious if IsFormatSupported should always return a > WAVE_FORMAT_EXTENSIBLE object. Aye indeed, seems to be an old copy/paste bug too. Was fixed on 27 Apr 2011 in winealsa. >> +static enum pa_channel_position pulse_map[] = { > This should probably be const. Yes. :) >> + if (fmt->wFormatTag == WAVE_FORMAT_IEEE_FLOAT) >> + This->ss.format = PA_SAMPLE_FLOAT32LE; > ... >> + if (IsEqualGUID(&wfe->SubFormat, &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)) >> + This->ss.format = PA_SAMPLE_FLOAT32LE; > You likely should check that the format specifies 32 bits, and not 64 or > something different like that. Yes indeed, I've moved those checks to a separate function now, Initialize was getting too long. I should probably use it for IsFormatSupported, but likely PulseAudio supports any sane format you throw at it, although I haven't tested the limits... Is it really IsFormatSupported's job to deal with a WAVEFORMATEX struct with only cbSize and wFormatTag and it will get out something sane all the time, no matter how stupid the input? This isn't an all-inclusive lookover, just some things that caught my eye. Also, does this driver fail to load if it can't connect to a pulse server? Yeah, mmdevapi checks priority, I set it to 0 if driver is unavailable, 3 if it is. See AUDDRV_GetPriority Thanks for reviewing, ~Maarten

Feb. 29, 2012

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)

by Henri Verbeet

On 29 February 2012 11:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > try 2: Invalidate the index buffer state as well, as the buffer might be > an index buffer. > > Otherwise unmodified reesend after the discussion from yesterday. This > is for bugs 29079, 29897(suspected) and 30019. > I guess I didn't explicitly say it yesterday, but I think this should be deferred and fixed properly after 1.4. While in principle dropping VBOs might be ok as a temporary fix for the release, the vertex / index buffer code is pretty fragile in general, and I can't guarantee that this won't introduce more regressions than it fixes.

Feb. 29, 2012

Re: RFT: Use Greek semicolons for comdlg32's printer status enumeration?

by Jerome Leclanche

Yes. Looks good. J. Leclanche On Wed, Feb 29, 2012 at 9:51 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Sat, 25 Feb 2012, Jerome Leclanche wrote: > [...] > > - I don't think an ano telia would be appropriate for this. To be honest > I > > don't even find a semicolon appropriate in English here. > > I don't build with printing support but it sounds to me like it would be > > more appropriate to use a comma, or a dash. > > Would the attached patch be better? > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > The greatest programming project of all took six days; on the seventh day > the > programmer rested. We've been trying to debug the *&^%$#@ thing ever > since. > Moral: design before you implement.

Feb. 29, 2012

Remove an obsolete string chunk fom the Swedish translation?

by Francois Gouget

This translation seems to have an extra example which is not present in the English string. Would it be ok to remove it? msgid "" "MOVE relocates a file or directory to a new point within the file system.\n" "\n" "If the item being moved is a directory then all the files and " "subdirectories\n" "below the item are moved as well.\n" "\n" "MOVE fails if the old and new locations are on different DOS drive letters.\n" msgstr "" "MOVE flyttar en fil eller mapp till ett nytt ställe inom filsystemet.\n" "\n" "Om du flyttar på en mapp, så flyttas allting under mappen med.\n" "\n" "MOVE misslyckas om den gamla och det den nya stället är på olika\n" "DOS-enhetsbokstäver. Till exempel från C: till D:.\n" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

Feb. 29, 2012

Re: RFT: Use Greek semicolons for comdlg32's printer status enumeration?

by Francois Gouget

On Sat, 25 Feb 2012, Jerome Leclanche wrote: [...] > - I don't think an ano telia would be appropriate for this. To be honest I > don't even find a semicolon appropriate in English here. > I don't build with printing support but it sounds to me like it would be > more appropriate to use a comma, or a dash. Would the attached patch be better? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

Feb. 29, 2012

Re: Major mmdevapi and winmm audio bugs

by Joerg-Cyril.Hoehle＠t-systems.com

Andrew Eikum wrote: >And, not too surprisingly, TimerQueue isn't sufficient. I've attached >my tests here. The tests ask to execute the callback every 12 ms. On >my Windows 7 VM, I found that it executed with intervals like: >20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ... >With an 11 occasionally interspersed. >So, forget that. No. Did you notice that on *average*, a callback occurs every 12ms (5 within 60ms)? This is the same essential property that winmm:setTimer exhibits too. Wine's CreateTimerQueue is buggy, because it doesn't do that. Wine's winmm:timer does. A patch is needed for CTQ. Now if Wine's CTQ would be fixed, Wine's audio would have fewer underruns. The periodicity is another topic. >my Windows 7 VM I don't trust timings from a VM. 10/20ms may be an artefact. OTOH it may be a design decision from MS related to scheduler quantums or whatever. >Since we're already using poll() in winmm and it seems to work well, >that would be my suggestion. Sure, but then you need an own thread in mmdevapi, don't you? So we're back at the point where I said earlier that I can well imagine a fix to CTQ for wine-1.4.0, but less so a move to an own thread + poll. Regards, Jörg Höhle

Feb. 29, 2012

Re: doc: Update Italian README

by Luca Bennati

2012/2/28 Frédéric Delanoy <frederic.delanoy(a)gmail.com> > 2012/2/28 Luca Bennati <lucak3(a)gmail.com>: > > I tried converting README.it to UTF8, instead of the current Extended > ASCII, > > which works really bad on my system. > > However, it does not seems like Git caught this change: could this be > done > > manually? > > I applied the patch manually and it seems the conversion went fine. > Maybe there were some accentuated letters already. > (hint: 'iconv' can be useful for those kind of conversions, or a save > with your favorite editor) > > BTW, > > -6. ESEGUIRE I PROGRAMMI > +6. RUNNING PROGRAMS > > seems wrong... > > Frédéric > It's good that it works as planned. Thanks for spotting that line, I've sent another patch to correct it.

Feb. 29, 2012

Re: gdiplus: Create a GDI brush only when needed.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > The right solution is to remove the gdibrush and logbrush fields from > GpBrush, and generate the HBRUSH as needed in brush_fill_path. Note > that brush_fill_path will only be called for solid and hatch brushes > (those for which brush_can_fill_path returns true), so we don't need > the code to create a gdi brush for the other types. Does the attached patch look better? Next step would be to get rid of bmp in GpSolidFill structure. -- Dmitry.

Feb. 29, 2012