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

Re: gdiplus: Create a GDI brush only when needed.
by Vincent Povirk Feb. 29, 2012

Feb. 29, 2012

This won't work. We create gdi32 brushes for hatch brushes based on temporary bitmaps that won't exist at the time brush_fill_path is called. On Wed, Feb 15, 2012 at 2:44 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > This patch fixes the problem reported in the bug 29894. > --- > dlls/gdiplus/brush.c | 19 ------------------- > dlls/gdiplus/gdiplus_private.h | 1 - > dlls/gdiplus/graphics.c | 13 ++++++++++++- > 3 files changed, 12 insertions(+), 21 deletions(-) > > diff --git a/dlls/gdiplus/brush.c b/dlls/gdiplus/brush.c > index d1af903..e0c400e 100644 > --- a/dlls/gdiplus/brush.c > +++ b/dlls/gdiplus/brush.c > @@ -55,7 +55,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > > memcpy(*clone, brush, sizeof(GpSolidFill)); > > - (*clone)->gdibrush = CreateBrushIndirect(&(*clone)->lb); > fill->bmp = ARGB2BMP(fill->color); > break; > } > @@ -123,8 +122,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > > memcpy(dest, src, sizeof(GpLineGradient)); > > - dest->brush.gdibrush = CreateSolidBrush(dest->brush.lb.lbColor); > - > count = dest->blendcount; > dest->blendfac = GdipAlloc(count * sizeof(REAL)); > dest->blendpos = GdipAlloc(count * sizeof(REAL)); > @@ -142,7 +139,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > GdipFree(dest->blendpos); > GdipFree(dest->pblendcolor); > GdipFree(dest->pblendpos); > - DeleteObject(dest->brush.gdibrush); > GdipFree(dest); > return OutOfMemory; > } > @@ -295,7 +291,6 @@ GpStatus WINGDIPAPI GdipCreateHatchBrush(HatchStyle hatchstyle, ARGB forecol, AR > (*brush)->brush.lb.lbStyle = BS_PATTERN; > (*brush)->brush.lb.lbColor = 0; > (*brush)->brush.lb.lbHatch = (ULONG_PTR)hbmp; > - (*brush)->brush.gdibrush = CreateBrushIndirect(&(*brush)->brush.lb); > > DeleteObject(hbmp); > } > @@ -307,7 +302,6 @@ GpStatus WINGDIPAPI GdipCreateHatchBrush(HatchStyle hatchstyle, ARGB forecol, AR > (*brush)->brush.lb.lbStyle = BS_SOLID; > (*brush)->brush.lb.lbColor = fgcol; > (*brush)->brush.lb.lbHatch = 0; > - (*brush)->brush.gdibrush = CreateBrushIndirect(&(*brush)->brush.lb); > } > > if (stat == Ok) > @@ -351,7 +345,6 @@ GpStatus WINGDIPAPI GdipCreateLineBrush(GDIPCONST GpPointF* startpoint, > (*line)->brush.lb.lbStyle = BS_SOLID; > (*line)->brush.lb.lbColor = col; > (*line)->brush.lb.lbHatch = 0; > - (*line)->brush.gdibrush = CreateSolidBrush(col); > (*line)->brush.bt = BrushTypeLinearGradient; > > (*line)->startpoint.X = startpoint->X; > @@ -387,7 +380,6 @@ GpStatus WINGDIPAPI GdipCreateLineBrush(GDIPCONST GpPointF* startpoint, > { > GdipFree((*line)->blendfac); > GdipFree((*line)->blendpos); > - DeleteObject((*line)->brush.gdibrush); > GdipFree(*line); > *line = NULL; > return OutOfMemory; > @@ -624,7 +616,6 @@ GpStatus WINGDIPAPI GdipCreatePathGradient(GDIPCONST GpPointF* points, > (*grad)->brush.lb.lbColor = col; > (*grad)->brush.lb.lbHatch = 0; > > - (*grad)->brush.gdibrush = CreateSolidBrush(col); > (*grad)->brush.bt = BrushTypePathGradient; > (*grad)->centercolor = 0xffffffff; > (*grad)->wrap = wrap; > @@ -719,7 +710,6 @@ GpStatus WINGDIPAPI GdipCreatePathGradientFromPath(GDIPCONST GpPath* path, > (*grad)->brush.lb.lbColor = col; > (*grad)->brush.lb.lbHatch = 0; > > - (*grad)->brush.gdibrush = CreateSolidBrush(col); > (*grad)->brush.bt = BrushTypePathGradient; > (*grad)->centercolor = 0xffffffff; > (*grad)->wrap = WrapModeClamp; > @@ -753,7 +743,6 @@ GpStatus WINGDIPAPI GdipCreateSolidFill(ARGB color, GpSolidFill **sf) > (*sf)->brush.lb.lbColor = col; > (*sf)->brush.lb.lbHatch = 0; > > - (*sf)->brush.gdibrush = CreateSolidBrush(col); > (*sf)->brush.bt = BrushTypeSolidColor; > (*sf)->color = color; > (*sf)->bmp = ARGB2BMP(color); > @@ -898,7 +887,6 @@ GpStatus WINGDIPAPI GdipCreateTextureIA(GpImage *image, > (*texture)->brush.lb.lbColor = 0; > (*texture)->brush.lb.lbHatch = (ULONG_PTR)hbm; > > - (*texture)->brush.gdibrush = CreateBrushIndirect(&(*texture)->brush.lb); > (*texture)->brush.bt = BrushTypeTextureFill; > (*texture)->image = new_image; > > @@ -1036,7 +1024,6 @@ GpStatus WINGDIPAPI GdipDeleteBrush(GpBrush *brush) > break; > } > > - DeleteObject(brush->gdibrush); > GdipFree(brush); > > return Ok; > @@ -1578,9 +1565,6 @@ GpStatus WINGDIPAPI GdipSetPathGradientCenterColor(GpPathGradient *grad, > grad->centercolor = argb; > grad->brush.lb.lbColor = ARGB2COLORREF(argb); > > - DeleteObject(grad->brush.gdibrush); > - grad->brush.gdibrush = CreateSolidBrush(grad->brush.lb.lbColor); > - > return Ok; > } > > @@ -1775,9 +1759,6 @@ GpStatus WINGDIPAPI GdipSetSolidFillColor(GpSolidFill *sf, ARGB argb) > sf->color = argb; > sf->brush.lb.lbColor = ARGB2COLORREF(argb); > > - DeleteObject(sf->brush.gdibrush); > - sf->brush.gdibrush = CreateSolidBrush(sf->brush.lb.lbColor); > - > return Ok; > } > > diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h > index 9afe15b..b597511 100644 > --- a/dlls/gdiplus/gdiplus_private.h > +++ b/dlls/gdiplus/gdiplus_private.h > @@ -170,7 +170,6 @@ struct GpGraphics{ > }; > > struct GpBrush{ > - HBRUSH gdibrush; > GpBrushType bt; > LOGBRUSH lb; > }; > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 65a3815..35aa504 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -723,10 +723,21 @@ static void brush_fill_path(GpGraphics *graphics, GpBrush* brush) > /* else fall through */ > } > default: > - SelectObject(graphics->hdc, brush->gdibrush); > + { > + HBRUSH gdibrush, old_brush; > + > + if (brush->lb.lbStyle == BS_SOLID) > + gdibrush = CreateSolidBrush(brush->lb.lbColor); > + else > + gdibrush = CreateBrushIndirect(&brush->lb); > + > + old_brush = SelectObject(graphics->hdc, gdibrush); > FillPath(graphics->hdc); > + SelectObject(graphics->hdc, old_brush); > + DeleteObject(gdibrush); > break; > } > + } > } > > static INT brush_can_fill_pixels(GpBrush *brush) > -- > 1.7.8.4 > > >

2 3

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)
by Henri Verbeet Feb. 29, 2012

Feb. 29, 2012

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.

2 2

Re: [PATCH] winepulse: Add pulse driver, v8
by Chris Robinson Feb. 29, 2012

Feb. 29, 2012

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? > +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. > +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. > +static enum pa_channel_position pulse_map[] = { This should probably be const. > + 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. 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?

3 2

RFT: Use Greek semicolons for comdlg32's printer status enumeration?
by Francois Gouget Feb. 29, 2012

Feb. 29, 2012

Request For Translators<g> So what I've gathered from Wikipedia is that the Greek language does not use semicolons as a separator for enumerations: http://en.wikipedia.org/wiki/Semicolon#Greek_and_Church_Slavonic | In Greek and Church Slavonic, a semicolon indicates a question, | similar to a Latin question mark.[2] To indicate a long pause or | separate sections, each with commas (the semicolon's purpose in | English), Greek uses an ano teleia ( · ). Wine uses semicolons as a separator in one place, for comdlg32's printer status enumeration. It's a list of status indicators separated by semicolons and looks like this: Error; Paper jam; or Initialising; Default Printer; I/O Active; So I would expect the Greek translation to use ano teleia characters as the separator but instead it uses plain semicolons: msgid "Paused; " msgstr "Σταματημένος; " msgid "Error; " msgstr "Σφάλμα; " msgid "Busy; " msgstr "Απασχολημένος; " So I'm hoping some Greek-speaking Wine hacker or user can enlighten me on the following points: * Did I understand Wikipedia wrong? Do both English semicolons and question marks translate to a semicolon in Greek? * Is this a special case that justifies not following the standard rule? If so why? * Does the attached patch replacing semicolons with ano teleia characters make sense? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

2 3

Remove an obsolete string chunk fom the Swedish translation?
by Francois Gouget Feb. 29, 2012

Feb. 29, 2012

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.

1 0

Re: doc: Update Italian README
by Frédéric Delanoy Feb. 29, 2012

Feb. 29, 2012

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

2 1

Re: [PATCH] README: updated Linux and FreeBSD kernels
by Francois Gouget Feb. 29, 2012

Feb. 29, 2012

On Wed, 22 Feb 2012, Marcus Meissner wrote: > --- > README | 13 ++++++------- > 1 files changed, 6 insertions(+), 7 deletions(-) > > diff --git a/README b/README > index baa6ab3..0cbb047 100644 > --- a/README > +++ b/README > @@ -29,7 +29,7 @@ especially the wealth of information found at http://www.winehq.org. > To compile and run Wine, you must have one of the following: > > Linux version 2.0.36 or above > - FreeBSD 6.3 or later > + FreeBSD 8.0 or later [...] > FreeBSD info: > - Wine will generally not work properly on versions before FreeBSD > - 6.3 or 7.0, and FreeBSD 6.3 has additional patches available. See > - http://wiki.freebsd.org/Wine for more information. > + Wine will generally not work properly on versions before FreeBSD 8.0. > + See http://wiki.freebsd.org/Wine for more information. Is there a reason why Wine won't work right on FreeBSD 7.0? Winetest seems mostly ok. http://test.winehq.org/data/f43f37d3613db57c732196f88e1225191cd62c30/index_… -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

2 1

Re: [PATCH] winepulse: Add pulse driver, v8
by Dmitry Timoshkov Feb. 28, 2012

Feb. 28, 2012

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > Date: Thu, 28 Apr 2011 09:45:18 +0200 > Subject: [PATCH 10/10] winepulse: Add pulse driver, v8 You forgot to fix the date, 1 Apr would be more appropriate I'd guess. -- Dmitry.

2 1

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic
by Henri Verbeet Feb. 28, 2012

Feb. 28, 2012

On 28 February 2012 12:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is for bug 30019. > > Out ddraw.dll forwards DDLOCK_DISCARDCONTENTS and DDLOCK_NOOVERWRITE to > wined3d, but wined3d ignores those flags because we never set > WINED3DUSAGE_DYNAMIC. D3d7 docs refer to D3DVBCAPS_WRITEONLY as the flag > to set when creating a buffer, so translate it to DYNAMIC | WRITEONLY. > > An argument could be made that we should set the DYNAMIC flag on all > d3d7 buffers, but until I see a game that needs it I prefer to keep > non-D3DVBCAPS_WRITEONLY buffers regular buffers. I don't see why WRITEONLY should imply DYNAMIC. Setting it for all ddraw buffers may make sense, but even then I'd like to hear a somewhat more convincing argument that now is the right time to change this.

2 3

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers
by Henri Verbeet Feb. 28, 2012

Feb. 28, 2012

On 28 February 2012 12:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is for bug 30019. > > They are a lot slower than using no VBO at all in at least some, if not all > games. The reason for the slowdown is the memcpy call, not the buffer > map. I don't find this all that convincing either. My impression is that the reason we have these kinds of problems is mostly that the buffer conversion code is broken. I don't think there are legitimate cases where not creating a VBO should improve performance.

2 3