[2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.

[Nikolay Sivov]

Michael Karcher wrote:
> Am Sonntag, den 13.07.2008, 13:51 +0400 schrieb Nikolay Sivov:
>   
>> Reece Dunn wrote:
>>     
>>> Is this the way it works on Windows? You have 4 basic cases:
>>> a.  exactly equal;
>>> b.  equal + epsilon for rounding/representation errors;
>>> c.  equal - epsilon for rounding/representation errors;
>>> d.  not equal.
>>>       
> I don't see a difference between b and c. A matrix has four elements.
> Some might be slightly too big and others slightly too small. Would this
> make b or c? It's just one case: equal +/- epsilon.
>
>   
>> Exactly, so I plan to test this deeper on native. As I see now after 
>> some basic tests, most probably native call does a bitwise comparison 
>> cause the result is affected by a smallest matrix element change (e.g. 
>> 1.0000000f -> 1.0000001f). But I'll test it more.
>>     
> 1+FLT_EPSILON is the value to use for the "smallest matrix element
> change". But sour test already is a very strong indication that it
> really is strict equality test. FLT_EPSILON is in <float.h>
>   
This header is optional, isn't it? I've used FLT_EPSILON in call PlgBlt 
of gdi32, but it was replaced with 1e-5 on commit (it was fabs(det) < 
FLT_EPSILON). So am I right that we can't use it on portability reason?
>> Reece, do you have any 
>> suggestions to do some bounds test (I mean test is call affected by 
>> representation or round errors or not)?
>>     
> Another thing you could test is: Is the Matrix (1,FLT_EPSILON/2,0,1)
> equal to (1,0,0,1). A matrix like te former can easily be the result of
> multiplying a matrix by its inverse matrix (if represented as floating
> point numbers). One might expect that the product of a matrix and its
> inverse always is the identity matrix.
>   
I'll try that.
>>>> 2. GdipIsMatrixInvertible which contains a check for 'not above zero'
>>>> determinant.
>>>>     
>>>>         
>>> a.  det(A) > 0
>>> b.  det(A) == 0
>>> c.  det(A) < 0
>>>
>>> So does Windows match your assumption for the answer to these (a ==>
>>> yes; b, c ==> no).   
>>>       
>> What do you mean here by (c => no)? Native allows negative det and I do so.
>>     
> He implied it form your "not above zero" quote.
Yes, I meant absolute value of course.
>  A hint how I would
> implement that test (if it turns out that a strict comparison to 0 is
> not the right result): Do not calculate the sum of a*d and -b*c, but
> compare these numbers in a sensible way.
>   
Here I something like FLT_EPSILON constant. So it's the same like above.
> Regards,
>   Michael Karcher
>
>