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

Re: comctl32/listview: fix mouse message sequences

by Nikolay Sivov

On 2/24/2013 17:52, Daniel Jelinski wrote: > 2013/2/24 Nikolay Sivov <bunglehead(a)gmail.com>: >> This doesn't look very clean. I mean invoking *up handler from a *down one. >> Is this something that could be resolved with message loop like rbutton >> dragging was fixed? > TrackMouse contains the message loop. It returns FALSE when it > receives LBUTTONUP (or any other button message), Okay, so why not let corresponding message handler to process it normally? > so calling LButtonUp > here is almost exactly what happened before. I'm not sure if inlining > the call would help here. > Regards, > Daniel >

Feb. 25, 2013

Re: winetest: Add a link to the test summary page that specifies the test configuration details, the dll versions, etc.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > Clarify two other link names to avoid confusion. > --- > > I did not test this patch so it should be verified carefully before > committing. I recently found myself annoyed that I could not go from a > page such as this one: > > http://test.winehq.org/data/209b58c64e6181c9bf448cb4f3130d3ba705c5d2/win7_n… > > to what I call that test's summary page: > > http://test.winehq.org/data/209b58c64e6181c9bf448cb4f3130d3ba705c5d2/win7_n… > > Of course 'summary' referred instead to the page with all the 'build > results' which I found very confusing. So I renamed it to just that > ('build results', not 'confusing' <g>). Then I renamed the 'index' link > to 'home' since it points to the winetest site's landing page (aka its > 'home' page). I'm not sure that's better. Particularly since that summary page is helpfully called "Main summary", it's not that confusing. The version info is obtained on other pages by clicking on the test tag, so we could potentially display the test tag on the individual test page too. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2013

Re: A new demangler test?

by Vincent Povirk

While this may be a useful exercise (and I'd personally like to see some demangler improvements, particularly support for managed references), this sort of broad test doesn't make sense for the Wine test suite, especially if we can't be sure it will always work on Windows. It's the sort of thing you could use to detect problems with our code, which you could then add a few individual tests for. Maybe it could be added to winezeug? Or is there a more appropriate place?

Feb. 25, 2013

Re: [2/3] gdiplus: Round up when converting from 32-bit ARGB to PARGB.

by Vincent Povirk

Never mind, this makes sense to me now.

Feb. 25, 2013

Re: [2/3] gdiplus: Round up when converting from 32-bit ARGB to PARGB.

by Vincent Povirk

Are you sure about this? Other tests have suggested that native is not this exact when dealing with color values, and different OS versions have produced slightly different results. Is there an application that relies on this, or is there a reason this is generally more correct behavior when premultiplying alpha?

Feb. 25, 2013

Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset

by Akihiro Sagawa

On Sun, 24 Feb 2013 09:55:59 +0900, Byeongsik Jeon wrote: Could you consider adding "(try N)" at the end of subject line? The rule is documented here: http://wiki.winehq.org/SubmittingPatches#head-fea51bfdf6a29105a9a6fc6f5886a… > diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c > index b274b83..3a99d35 100644 > --- a/dlls/gdi32/font.c > +++ b/dlls/gdi32/font.c > @@ -590,11 +590,75 @@ HFONT WINAPI CreateFontW( INT height, INT width, INT esc, This part looks good. > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c (snip) > +static void update_font_association_info(UINT current_ansi_codepage) > +{ > + static const WCHAR font_assoc_reg_keyW[] = {'S','y','s','t','e','m','\\', > + 'C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t','\\', > + 'C','o','n','t','r','o','l','\\','F','o','n','t','A','s','s','o','c','\0'}; It is nice introducing separate function for this work. However using WCHAR is a bit overwork, because ANSI APIs are still used in update_font_info() especially set_value_key(). Please follow the style of surrounding code. > @@ -3615,6 +3675,10 @@ static void update_font_info(void) > } > if (!done) > FIXME("there is no font defaults for codepages %u,%u\n", ansi_cp, oem_cp); > + > + /* update locale dependent font association info in registry */ > + if (strcmp(buf, cpbuf)) > + update_font_association_info(ansi_cp); > } > > static BOOL init_freetype(void) This condition should be rewritten. buf is not initialized when RegQueryValueExA is failed in line 3542. And strcmp(buf, cpbuf) has already done in line 3544. > diff --git a/dlls/gdi32/tests/font.c b/dlls/gdi32/tests/font.c > index 943f584..9d57806 100644 > --- a/dlls/gdi32/tests/font.c > +++ b/dlls/gdi32/tests/font.c Why are there no tests against OEM_CHARSET and SYMBOL_CHARSET? Regards, Akihiro Sagawa

Feb. 25, 2013

Re: d3dx9: Avoid expensive computations

by Henri Verbeet

On 25 February 2013 12:26, Rico Schüller <kgbricola(a)web.de> wrote: > Is there a reason why we don't use sse instructions? Or did just no one had > a look at it yet? I think on the one hand there hasn't been much of a need so far, and on the other hand you'd probably need something along the lines of STT_GNU_IFUNC to make it work properly.

Feb. 25, 2013

Re: d3dx9: Avoid expensive computations

by Nozomi Kodama

Rico, can you give a try to this patch? If it is slightly slower than native, we could at first merge it. Anyway, if the application is well coded, this function should not be called often. Usually an application uses transformations matrices that are a lot easier to inverse Nozomi ________________________________ De : Henri Verbeet <hverbeet(a)gmail.com> À : Rico Schüller <kgbricola(a)web.de> Cc : wine-devel(a)winehq.org; Nozomi Kodama <nozomi.kodama(a)yahoo.com> Envoyé le : Lundi 25 février 2013 0h08 Objet : Re: d3dx9: Avoid expensive computations On 25 February 2013 10:24, Rico Schüller <kgbricola(a)web.de> wrote: > I did some small tests for speed with the following results. You may also > avoid such a lot of variable assignments like *pout = out and you may use 4 > vecs instead. This should save ~48 assignments and it should also improve > the speed a bit more (~10%). Though, native is still 40% faster than that. > I'd somewhat expect native to use SSE versions of this kind of thing when the CPU supports those instructions. You also generally want to pay attention to the order in which you access memory, although perhaps it doesn't matter so much here because an entire matrix should be able to fit in a single cacheline, provided it's properly aligned.

Feb. 25, 2013

Re: d3dx9: Avoid expensive computations

by Rico Schüller

On 25.02.2013 11:08, Henri Verbeet wrote: > On 25 February 2013 10:24, Rico Schüller <kgbricola(a)web.de> wrote: >> I did some small tests for speed with the following results. You may also >> avoid such a lot of variable assignments like *pout = out and you may use 4 >> vecs instead. This should save ~48 assignments and it should also improve >> the speed a bit more (~10%). Though, native is still 40% faster than that. >> > I'd somewhat expect native to use SSE versions of this kind of thing > when the CPU supports those instructions. You also generally want to > pay attention to the order in which you access memory, although > perhaps it doesn't matter so much here because an entire matrix should > be able to fit in a single cacheline, provided it's properly aligned. > Is there a reason why we don't use sse instructions? Or did just no one had a look at it yet?

Feb. 25, 2013

Re: d3dx9: Avoid expensive computations

by Henri Verbeet

On 25 February 2013 10:24, Rico Schüller <kgbricola(a)web.de> wrote: > I did some small tests for speed with the following results. You may also > avoid such a lot of variable assignments like *pout = out and you may use 4 > vecs instead. This should save ~48 assignments and it should also improve > the speed a bit more (~10%). Though, native is still 40% faster than that. > I'd somewhat expect native to use SSE versions of this kind of thing when the CPU supports those instructions. You also generally want to pay attention to the order in which you access memory, although perhaps it doesn't matter so much here because an entire matrix should be able to fit in a single cacheline, provided it's properly aligned.

Feb. 25, 2013