[ros-bugs] [Bug 3412] pictures and fax viewer doesnt draw picture

[ReactOS.Bugzilla at reactos.org]

http://www.reactos.org/bugzilla/show_bug.cgi?id=3412





--- Comment #3 from vicmarcal <vicmarcal at hotmail.com>  2009-11-27 15:44:12 CET ---
Created an attachment (id=4433)
 --> (http://www.reactos.org/bugzilla/attachment.cgi?id=4433)
Comparing Traces


Hi, im giving a sight to this issue. 
Now JPGs are loaded correctly, but BMPs doesnt.

Here goes my findings, so maybe it can help

******************ISSUES FOUND **********************
**************when loading a BMP Image***************

This is the current chain to load a BMP image:
Imageview_drawimage->GdipDrawImageRect->GdipGetImageBounds->GdipDrawImageRectRect->GdiPDrawImagePointsRect
and stopped here since i found some issues:

Issues at GdiPDrawImagePointsRect:

1)Here there is an odd funcion called "transform_and_round_points" (at
graphics.c)
--First odd thing in that function is:
"* Native gdiplus uses gdi32 to do all this (via SetMapMode, SetViewportExtEx,
 * SetWindowExtEx, SetWorldTransform, etc.) but we cannot because we are using
 * gdi to draw, and these functions would irreparably mess with line widths."
(Why dont we use gdi32?Sould we rewrite this transform functions with GDI32?)

--Second odd thing: It returns quite long values in pti[].x and pti[].y: 
i.e(pti[1].y:18446744071562067968)

2)At GdiPDramImagePointsRect when loading a BMP we go across this piece of
code:
            INT temp;
            temp = pti[0].y;
            pti[0].y = pti[2].y;
            pti[2].y = temp;
Why are we storing big values in an INT(see Issue1)?Wouldnt it chunk the value?

3)At GdiPDramImagePointsRect we check this condition:
IF(IPicture_Render(image->picture, graphics->hdc,
            pti[0].x, pti[0].y, pti[1].x - pti[0].x, pti[2].y - pti[0].y,
            srcx * dx, srcy * dy,
            srcwidth * dx, srcheight * dy,
            NULL) != S_OK){

Here seems to be 2 bugs: 
a)Wrong Params?Look to  pti[1].x - pti[0].x, pti[2].y - pti[0].y params.
They dont look consistent from my newbie POV.

b)Tracing shows that when we arrive here values are:
 pti[1].x =pti[0].x=000000 so pti[1].x - pti[0].x=Cx is Zero.
So we are passing a Zero to IPicture_Render as the argument "CX". If Cx is
Zero,
IPicture_Render should return CTL_E_INVALIDPROPERTYVALUE(instead S_OK)
according to MSDN
http://msdn.microsoft.com/en-us/library/ms682202%28VS.85%29.aspx
and return with Error. Nowadays seems our IPicture_Render doesnt complain.And
we dont go inside the IF and jump it.

******************************************
**************************Doubts**********
I want to catch this bug but i have some doubts:

What are we checking with if (image->picture)?what are we storing in the
IPicture variable of the struct GpImage?
Seems this value is 0 for JPG images but a variable number for a BMP image.

************           ****************
************TRACE ADDED****************
I am adding the Results of some TRACES added to graphics.c. It compares the
load of a BMP image against JPG image.


-- 
Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.