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

Re: d3dx9: Avoid expensive computations

by Rico Schüller

On 25.02.2013 06:03, Nozomi Kodama wrote: > + out.u.m[2][i] = v.z / signed_det; > + out.u.m[3][i] = v.w / signed_det; > } > > *pout = out; While you are at it, you may fix the indentation of out*, "}", "*pout = out;" and "return pout;". > signed_det = (i % 2)? -det: det; Couldn't you just use something like "det = -det;" instead of the modulo? This should be a little bit faster. 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. With the change above it should look like: int i; D3DXVECTOR4 v, vec[4]; FLOAT det; ... for (i = 0; i < 4; i++) { vec[i].x = pm->u.m[i][0]; vec[i].y = pm->u.m[i][1]; vec[i].z = pm->u.m[i][2]; vec[i].w = pm->u.m[i][3]; } for (i = 0; i < 4; i++) { switch (i) { case 0: D3DXVec4Cross(&v, &vec[1], &vec[2], &vec[3]); break; case 1: D3DXVec4Cross(&v, &vec[0], &vec[2], &vec[3]); break; case 2: D3DXVec4Cross(&v, &vec[0], &vec[1], &vec[3]); break; case 3: D3DXVec4Cross(&v, &vec[0], &vec[1], &vec[2]); break; } pout->u.m[0][i] = v.x / det; pout->u.m[1][i] = v.y / det; pout->u.m[2][i] = v.z / det; pout->u.m[3][i] = v.w / det; det = -det; } return pout; Maybe we could reuse some calculations from the D3DXVec4Cross function ... Cheers Rico

Feb. 25, 2013

Re: user32/tests: Test invalidating during SetWindowPos() (resend).

by Alexandre Julliard

Sergey Guralnik <serhio(a)etersoft.ru> writes: > On 2013-02-21 15:44, Sergey Guralnik wrote: >> > > This patch marked as "Pending" without any comment at wine-devel. > Is something wrong with it? (Maybe there should be more test cases?) Maybe, but it's not clear what you are trying to demonstrate with this. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2013

Re: user32/tests: Test invalidating during SetWindowPos() (resend).

by Sergey Guralnik

On 2013-02-21 15:44, Sergey Guralnik wrote: > This patch marked as "Pending" without any comment at wine-devel. Is something wrong with it? (Maybe there should be more test cases?) -- Sergey

Feb. 25, 2013

Re: [1/3] gdiplus: Add some tests for ARGB conversions.

by Nikolay Sivov

On 2/25/2013 09:29, Dmitry Timoshkov wrote: It seems your system time is an hour ahead. Probably old timezone info?

Feb. 25, 2013

Re: A new demangler test?

by Max TenEyck Woodbury

On 02/24/2013 04:18 AM, Nikolay Sivov wrote: > By the way, do you see something broken or it's just something you want > to work on? > Partly broken. If fed a bad string, it sometimes blows up and sometimes returns an error code. The 'real' routine also blows up on some strings. Which strings depends on the windows version. That means there is no specific bug we have to match, so it would make sense to do it right (that is return an error code) in all cases. Is that OK? In my opinion, the search for names is fairly important, but it may not belong in a msvcrt test. It might be better as part of a dbghelp test or in some other utility test. That search should work in a windows environment as well as a Wine environment. It should almost certainly check all the '.dll's in 'C:\windows\system*' and possibly a few other places where mangled names are likely to be found... But I have to admit, it is also something I want to work on...

Feb. 24, 2013

Re: Why complain about X1R5G5B5?

by Francois Gouget

On Sat, 23 Feb 2013, Henri Verbeet wrote: > On 23 February 2013 17:20, Henri Verbeet <hverbeet(a)gmail.com> wrote: > > Personally, I suspect the test is just overly restrictive. > > Also, just to clarify something, initially on IRC I was under the > impression the driver *only* exposed X1R5G5B5, i.e. instead of > X8R8G8B8, while clearly supporting 32 bpp display modes. Yes, that's probably my fault as that's what I believed too initially. But I have since run tests to list all the supported format and QXL exposes both X1R5G5B5 and X8R8G8B8: http://newtestbot.winehq.org/JobDetails.pl?Key=243&log_103=1#k103 -- Francois Gouget <fgouget(a)codeweavers.com>

Feb. 24, 2013

Re: comctl32/listview: fix mouse message sequences

by Daniel Jelinski

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), so calling LButtonUp here is almost exactly what happened before. I'm not sure if inlining the call would help here. Regards, Daniel

Feb. 24, 2013

Re: A new demangler test?

by Nikolay Sivov

On 2/24/2013 15:13, Eric Pouech wrote: > Le 24/02/2013 10:18, Nikolay Sivov a écrit : >> On 2/24/2013 10:07, Max TenEyck Woodbury wrote: >>> On 02/23/2013 02:54 AM, Eric Pouech wrote: >>>> Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : >>>>> Would it be appropriate to add a test to the name demangler that: >>>>> >>>>> 1) Scans all '.dll' and '.spec' files for mangled names, and >>>>> >>>>> 2) Tries to decode those names. >>>>> >>>>> 3) Prints the mangled and decoded names and where they occur. >>>>> >>>>> Success would be that all names decode without the decoder blowing up >>>>> or failing. >>>>> >>>>> >>>>> >>>> adding tests for demangler is good >>>> but you just need to have a set of mangled/unmangled strings for >>>> the test >>>> as core demangler in msvcrt, test should be added here... >>>> (but grabbing the mangled strings shall be left out of the test >>>> itself) >>>> A+ >>>> >>> One of the important aspects of name demangling is that it should work >>> on _all_ the names in the current system. The current test does >>> demangle a list of known strings, but that list was incomplete with >>> respect to all the features used in real names the last time I dug into >>> the details (which was none too recently). >>> >>> Scanning for all the real mangled names not only makes sure that the >>> demangler is working properly, it also assures that all the names used >>> are properly formed and decode to their intended values. >> I don't see a point to extend test data that much, it's enough to add >> some most common cases, >> and add more when something breaks because of it. Otherwise it >> doesn't deserve that much of attention imho. >> >> By the way, do you see something broken or it's just something you >> want to work on? >>> >>> > there are lots of broken stuff (in msvcrt), and demangler in winedump > is ante-deluvian (and doesn't share its code with msvcrt) > A+ Okay, don't know if winedump part is of any use, I mean it tries to provide a sane C name for decorated names, and usually such names are hand-crafted anyway later. Msvcrt being broken is important of course (at least for dbghelp).

Feb. 24, 2013

Re: comctl32/listview: fix mouse message sequences

by Nikolay Sivov

On 2/24/2013 01:33, Daniel Jelinski wrote: > @@ -10178,6 +10139,19 @@ static LRESULT LISTVIEW_LButtonDown(LISTVIEW_INFO *infoPtr, WORD wKey, INT x, IN > > if (infoPtr->dwLvExStyle & LVS_EX_ONECLICKACTIVATE) > if(lvHitTestInfo.iItem != -1) notify_itemactivate(infoPtr,&lvHitTestInfo); > + if (LISTVIEW_TrackMouse(infoPtr, pt)) > + { > + NMLISTVIEW nmlv; > + > + ZeroMemory(&nmlv, sizeof(nmlv)); > + nmlv.iItem = lvHitTestInfo.iItem; > + nmlv.ptAction = infoPtr->ptClickPos; > + > + notify_listview(infoPtr, LVN_BEGINDRAG, &nmlv); > + infoPtr->bDragging = TRUE; > + } > + else > + LISTVIEW_LButtonUp(infoPtr,0,x,y); 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?

Feb. 24, 2013

Re: A new demangler test?

by Nikolay Sivov

On 2/24/2013 10:07, Max TenEyck Woodbury wrote: > On 02/23/2013 02:54 AM, Eric Pouech wrote: >> Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : >>> Would it be appropriate to add a test to the name demangler that: >>> >>> 1) Scans all '.dll' and '.spec' files for mangled names, and >>> >>> 2) Tries to decode those names. >>> >>> 3) Prints the mangled and decoded names and where they occur. >>> >>> Success would be that all names decode without the decoder blowing up >>> or failing. >>> >>> >>> >> adding tests for demangler is good >> but you just need to have a set of mangled/unmangled strings for the >> test >> as core demangler in msvcrt, test should be added here... >> (but grabbing the mangled strings shall be left out of the test itself) >> A+ >> > One of the important aspects of name demangling is that it should work > on _all_ the names in the current system. The current test does > demangle a list of known strings, but that list was incomplete with > respect to all the features used in real names the last time I dug into > the details (which was none too recently). > > Scanning for all the real mangled names not only makes sure that the > demangler is working properly, it also assures that all the names used > are properly formed and decode to their intended values. I don't see a point to extend test data that much, it's enough to add some most common cases, and add more when something breaks because of it. Otherwise it doesn't deserve that much of attention imho. By the way, do you see something broken or it's just something you want to work on? > > >

Feb. 24, 2013