We can decide the data type 32/64 bits on compile time then. That will be a good option for quality and performance. Probably I can improve this.
here my change only affects to the corner case that uses large range of values but it rarely requested. But considering your advice, I don't know which case is the best among 16.16 / 20.12 /18.14. It's up to case by case so I need to find out the best one. By the way, enjoy vacation, dont read commits. :-) -----Original Message----- From: "Carsten Haitzler"<[email protected]> To: "Enlightenment developer list"<[email protected]>; Cc: Sent: 2016-09-12 (월) 17:24:26 Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: evas map: fix the rendering problem. On Mon, 12 Sep 2016 01:06:25 -0700 ChunEon Park <[email protected]> said: from memory i did 16.16. you could try doing 20.12 for example or 18.14 to avoid/reduce overflows. 64bit would of course be slower on 32bit cpu's. on 64bit cpu's it would be the best option for sure. > 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 > > -- > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
