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

Re: [1/3] wininet: Remember that headers were not received.

by Jacek Caban

Hi Ričardas, On 02/27/13 00:07, Ričardas Barkauskas wrote: > @@ -5708,6 +5708,7 @@ static INT HTTP_GetResponseHeaders(http_request_t *request, BOOL clear) > > heap_free(request->rawHeaders); > request->rawHeaders = heap_strdupW(szDefaultHeader); > + request->flags |= INTERNET_REQFLAG_NO_HEADERS; I don't think we want to maintain valid request->flags for that particular flag. Checking for request->rawHeaders should be enough. If we avoided setting rawHeaders here, we'd achieve the same behaviour. Jacek

Feb. 27, 2013

Re: msvcrt/tests: Mark win8 behaviour as broken

by Piotr Caban

On 02/26/13 23:57, André Hentschel wrote: > diff --git a/dlls/msvcrt/tests/time.c b/dlls/msvcrt/tests/time.c > index 30d9fa7..3d00769 100644 > --- a/dlls/msvcrt/tests/time.c > +++ b/dlls/msvcrt/tests/time.c > @@ -181,8 +181,8 @@ static void test_gmtime(void) > err = p_gmtime32_s(&gmt_tm_s, &gmt); > - ok(gmt_tm_s.tm_year==-1 || broken(gmt_tm_s.tm_year==70 && gmt_tm->tm_sec<0), > - "tm_year = %d\n", gmt_tm_s.tm_year); > + ok(gmt_tm_s.tm_year==-1 || broken(gmt_tm_s.tm_year==70), > + "tm_year = %d, tm_sec = %d\n", gmt_tm_s.tm_year, gmt_tm->tm_sec); This test was checking wrong structure. It should use gmt_tm_s struct for testing seconds instead of gmt_tm.

Feb. 27, 2013

Re: [1/3] wininet: Remember that headers were not received.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24535 Your paranoid android. === W7PROX64 (32 bit http) === http.c:3337: Test failed: HttpSendRequest failed: 12002

Feb. 26, 2013

Re: d3dx9: Avoid expensive computations

by Rico Schüller

Hi Nozomi, this is pretty fast. Just some numbers (run time on my machine, so it might not be that representative)... before: 43s previous patch: 27s this patch: 21s native: 16s So from the speed point of view, it's a lot closer than the rest. Though, I would split this into 2 patches, one for D3DXMatrixDeterminant and one for D3DXMatrixInverse. I think it's a nice step forward. Thought we might test the speed of an sse version and may use it later ... Are there any other opinions? Cheers Rico On 25.02.2013 12:34, Nozomi Kodama wrote: > 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 > <mailto: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. 26, 2013

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

by Akihiro Sagawa

On Tue, 26 Feb 2013 10:42:14 +0900, Byeongsik Jeon wrote: > > 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. > > > I wanted to update in registry when codepages changed, not logpixels. When > logpixels has been changed, MS-Windows does not update the font associated > charset registry. "memset(buf, 0, sizeof(buf))" has been added. Good work. I got it. Including other changes, it looks good for me. Please send your patch to wine-patches. Akihiro Sagawa

Feb. 26, 2013

Re: riched20: Remove redundant 'return;' statements.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This patch is marked as 'Rejected', and I can't find an e-mail to wine-devel > with an explanation why. It's a matter of taste, so you can't change other people's code. -- Alexandre Julliard julliard(a)winehq.org

Feb. 26, 2013

Re: d3dx9: Avoid expensive computations

by David Laight

On Mon, Feb 25, 2013 at 11:08:02AM +0100, 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. Also make sure that are memory that is written to can't be aliased by the memory that is read. If aliasing is possible the compiler has sequence the code to ensure the writes and reads happen in the correct order. That function probably has too many live values for the normal registers - so some values will get flushed to stack. SSE might be better. David -- David Laight: david(a)l8s.co.uk

Feb. 26, 2013

Re: comctl32/listview: fix mouse message sequences

by Daniel Jelinski

2013/2/25 Nikolay Sivov <bunglehead(a)gmail.com>: > 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? Short answer: because that's how native behaves. They don't call DispatchMessage on button messages received in message loop, so neither do we. According to this MSDN page: http://msdn.microsoft.com/en-us/library/windows/desktop/bb774734%28v=vs.85%… Listview window procedure does not handle MOUSEMOVE and *BUTTONUP messages. My experience with +message logs seems to confirm that. Every time when any action happens in response to *BUTTONUP, it is contained in some kind of message loop. My long term goal is to remove these handlers from wine's implementation as well. I wanted to remove call to LISTVIEW_LButtonUp from window proc already, but unfortunately marquee selection still depends on it.

Feb. 26, 2013

Re: riched20: Remove redundant 'return;' statements.

by Dmitry Timoshkov

This patch is marked as 'Rejected', and I can't find an e-mail to wine-devel with an explanation why. -- Dmitry.

Feb. 26, 2013

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

by Byeongsik Jeon

Thank you. Review again before submitting a patch to wine-patches, please. On 02/26/13 00:08, Akihiro Sagawa wrote: > On Sun, 24 Feb 2013 09:55:59 +0900, Byeongsik Jeon wrote: > >> @@ -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. > I wanted to update in registry when codepages changed, not logpixels. When logpixels has been changed, MS-Windows does not update the font associated charset registry. "memset(buf, 0, sizeof(buf))" has been added. >> 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? > In the current Wine code, if lfCharset == OEM_CHARSET then GetTextCharset() return a wrong value. This problem can be found in the test_oemcharset(). At this point, I wanted to concentrate on the ANSI_CHARSET association problem.

Feb. 26, 2013