On Mon, 12 Sep 2016 18:15:57 +0900 (KST) Hermet Park <[email protected]> said:
> 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. probably this is a good idea. on 64bit systems we can use full 64bit ints (long long's) with no penalty. > 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. well one thing that can be done is... move the code to a file, #include it and #define the bit precision before #including (so the #included file then modifies its bit precision based on defines and <</>>'s the amount defined) then... code higher up chooses the precision to use by using that specific path. like: #define PRECISION 8 #define FUNCNAME mapcode_8 #include "mapcode.c" #undef FUNCNAME #undef PRECISION #define PRECISION 10 #define FUNCNAME mapcode_10 #include "mapcode.c" #undef FUNCNAME #undef PRECISION #define PRECISION 12 #define FUNCNAME mapcode_12 #include "mapcode.c" #undef FUNCNAME #undef PRECISION #define PRECISION 114 #define FUNCNAME mapcode_14 #include "mapcode.c" #undef FUNCNAME #undef PRECISION #define PRECISION 16 #define FUNCNAME mapcode_16 #include "mapcode.c" #undef FUNCNAME #undef PRECISION and "mapcode.c" is just the internal map code split out into a function and it just does val << PRECISION ... val >> PRECISION where now the bitshifts are fixed constants. :) now you can have various precision versions and choose the one based on input coordinates to ensure we dont overflow. :) call mapcode_12(x,y,z) or mapcode_14(x,y,z) etc. :) how about this? then problems solved across various ranges. and of course 64bit can just have a single 64bit implementation with long long instead of int :) > 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 -- ------------- 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
