evas map: fix the rendering problem.
authorHermet Park <hermet@hermet.pe.kr>
Mon, 12 Sep 2016 07:50:00 +0000 (16:50 +0900)
committerHermet Park <hermet@hermet.pe.kr>
Mon, 12 Sep 2016 07:50:00 +0000 (16:50 +0900)
I got an issue report about map rendering.
After investigated, I found that was introduced by data overflow.

For fast computation, evas map uses integer data type rather than float,
that gives up some range of data size.

So, if vertex range is a little large but still reasonable,
polygon won'be properly displayed due to the integer overflow.

We can fix this by changing FPc data type to 64 bits (ie, long long)
But I didn't do yet though I can simply fix this costlessly.

By the way, my test case map points are below.

0: -1715, -5499
1: -83, -1011
2: 1957, 5721
3: 325, 1233

and gl result is perfect but sw is totally broken.

@fix

src/lib/evas/common/evas_map_image.c

index 252bd3b..2a48b20 100644 (file)
@@ -183,8 +183,15 @@ _calc_spans(RGBA_Map_Point *p, Line *spans, int ystart, int yend, int cx, int cy
              edge_h = (p[e2].y - p[e1].y) >> FP;  //edge height
              if (edge_h < 1) edge_h = 1;
              t = (((y << FP) + (FP1 / 2) - 1) - p[e1].y) >> FP;
-             x= p[e2].x - p[e1].x;  //edge width
-             x = p[e1].x + ((x * t) / edge_h); // intersected x point
+             x = p[e2].x - p[e1].x;  //edge width
+
+             FPc temp = (x * t);
+
+             // TODO: prevent data overflow. We can remove this exception if FPc type is more than integer.
+             if (temp < 0) temp = (((x >> FP) * t) / edge_h) << FP;
+             else temp /= edge_h;
+
+             x = p[e1].x + temp; // intersected x point
 
 /*             
              // FIXME: 3d accuracy here