We need a proper interface to toggle high-quality mapping,
until that, we disable the anti_aliasing feature.
Since adjecent polygons(such as textpath) shouldn't get this aa feature.
Remove old anti-alias code since high quality map is replaced with new one.
New anti-aliasing is logically same but having a regression bug,
it should be stablized.
Summary:
This new implementation of evas map texture mapping
is designed for high quality rendering same level to GL.
If you use a high-end device, performance is not too bad, you can turn this on.
You might have practical image quality even in software rendering.
Since this implementation still have a few optimization points (+simd)
and stablizings, it may be useful in somewhat limited envrionments right now.
However the functionality definitely works fine, so please turn this on by
demand (anti_alias + smooth) for a while.
{F3667773} {F3667776} {F3667778}
Reviewers: #committers, devilhorns, raster
Reviewed By: #committers, raster
Subscribers: raster, devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8106
Moved rects caching into draw context to avoid the use of __thread
slot. Draw context are defined per thread anyway and should be just
fine. This doesn't really change the picture regarding glibc problem
when to many __thread are needed, but slightly improve the global
picture. Also this patch doesn't affect our performance in expedite
benchmark as far as I can tell.
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
this works with 7166e6b859 and fixes a
leak added because ... free does not free!
evas_common_draw_context_cutouts_real_free(0 now actually frees the
rects, but evas_common_draw_context_cutouts_free() before did not.
@fix (follow on from 7166e6b859)
this fixes the fix 4d6a8a7fce to be
portable to platfomrs that do not support __thread - seemingly openbsd
does not (argh!) and maybe others. so on these platforms then they
dont get the optimization of keeping a cutout rect pool to avoid
re-allocation.
this also every 4096 draws "resets" the cutout cache so it doesnt
expand and stay expanded forever.
@fix
several draw funcs keep a static Cutout_Rect *rects = NULL; variable
to cache cutout rects to avoid re-allocating them a lot etc. this is
fast and handy but we may use these from multiple threads. thats bad
.... mmmkay. so this fixes it the dirty way - makes them thread local.
:)
this fixes T3348 - the crash mentioned by @zmike
@fix
Clipper causes the different rendering result by last 1 pixel on the width.
Because the left edge x range (0 ~ (w - 1)) and right edge x range (0 ~ w) is different.
This fix won't be memory over access problem even if x span position is on the end of the edge.
Because the span width(x2 - x1) will be 0, and it restuls in skipping drawing.
It's hardly find the problem but you can detect the subtle rendering difference when some arbitrary meshes with map is
You can compare image and rectangle map drawing for this.
@fix
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.
This patch should make us get a reference on images, maps and glyphs
which are sent in a command to the render thread. Before we were doing
some useless ref and unref operations.
SVN revision: 82666
This patch refactors common code for map draws - so that it can be used
by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79855
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895