2013/2/25 Nikolay Sivov :
> On 2/24/2013 17:52, Daniel Jelinski wrote:
>>
>> 2013/2/24 Nikolay Sivov :
>>>
>>> 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?
>>
>> Tr
This patch is marked as 'Rejected', and I can't find an e-mail to wine-devel
with an explanation why.
--
Dmitry.
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 n
On 2/24/2013 17:52, Daniel Jelinski wrote:
2013/2/24 Nikolay Sivov :
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 whe
Francois Gouget 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/209b58c64e61
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 yo
Never mind, this makes sense to me now.
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 prem
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-fea51bfdf6a29105a9a6fc6f5886ad0653ae95e5
> diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c
> inde
On 25 February 2013 12:26, Rico Schüller 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 t
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
_
On 25.02.2013 11:08, Henri Verbeet wrote:
On 25 February 2013 10:24, Rico Schüller 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 s
On 25 February 2013 10:24, Rico Schüller 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 mo
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
Sergey Guralnik 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.
--
Alexa
15 matches
Mail list logo
