hermet pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=e8fcc41e40dee07d062bff51636e464ff9d98215
commit e8fcc41e40dee07d062bff51636e464ff9d98215 Author: Hermet Park <[email protected]> Date: Mon Sep 12 16:50:00 2016 +0900 evas map: fix the rendering problem. 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 | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/lib/evas/common/evas_map_image.c b/src/lib/evas/common/evas_map_image.c index 252bd3b..2a48b20 100644 --- a/src/lib/evas/common/evas_map_image.c +++ b/src/lib/evas/common/evas_map_image.c @@ -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 --
