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

Reply via email to