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

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

29 Feb '12

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 29 Feb '12

29 Feb '12

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 29 Feb '12

29 Feb '12

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 29 Feb '12

29 Feb '12

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 29 Feb '12

29 Feb '12

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 29 Feb '12

29 Feb '12

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] winepulse: Add pulse driver, v8
by Dmitry Timoshkov 28 Feb '12

28 Feb '12

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 28 Feb '12

28 Feb '12

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 28 Feb '12

28 Feb '12

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

Re: A small cs.po file update
by Francois Gouget 28 Feb '12

28 Feb '12

On Mon, 27 Feb 2012, David wrote: > Hello. > > There is attached a small cs.po update. Gzipped. Generated using > winepo. More is coming. I am planning to update it all. Last will be > translation of certificates/encryption strings. Thanks for the translation update. Unfortunately the tool you used to edit the PO file converted all the line ends from LF to CR+LF. The resulting diff was not so small as it contained the whole file twice. I have cleaned it up and rediffed it for this time (and I'll try to modify winepo to detect this). Some notes about the patch: -#, fuzzy msgid "&Modify..." msgstr "Z&měnit" msgid "&Install" -msgstr "&Instalovat" +msgstr "Na&instalovat..." The ellipses don't match here. Ellipses are very important because, for instance, they make all the difference between a 'Print' button that will send the page to the default printer right away, and a 'Print...' button that will first display a dialog that will let you choose the destination printer or cancel before anything happens. These look like th eonly two issues so things are looking pretty good. msgid "" "Is '%1' a filename or directory\n" "on the target?\n" "(F - File, D - Directory)\n" msgstr "" "Je '%1' název souboru nebo adresáře\n" "v cíli?\n" "(F - Soubor, D - Adresář)\n" It would probably be more intuitive for users if you change the 'shortcut keys': "(S - Soubor, A - Adresář)\n" And then modify the two other corresponding translations: msgctxt "File key" msgid "F" msgstr "S" msgctxt "Directory key" msgid "D" msgstr "A" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A black hole is just God dividing by zero.

1 0