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
Evas map supports anti-alias(aa) rendering on sw backened.
When aa is toggled on, map forcely turns alpha channel on while it draws on the surface.
Actually, it was intended to blend polygon edges with destination,
but it breaks one case if the original source image alpha channel were turned off.
Simply, it fixed the issue, new implmentation removes the alpha channel switching,
instead fill the alpha values with 255 when map + aa + alpha_off is drawing on it.
@fix T1975
Well... actually this is not exactly a fix.
It just restores the previous behaviour, and allows AA to
work. As in, it won't draw ugly black lines but properly
blend to transparent.
But there is still a problem:
The image map render function changes the alpha flag on the source
image if AA is enabled or if the map has an alpha color. This is
actually wrong as images forcefully set to not have any alpha
(with evas_object_image_alpha_set(0)) will then not be opaque
anymore.
Right now I can't think of a solution (also I don't quite follow
the entire pipeline in evas map...). Changing the flag will
make some opaque areas transparent. Not changing the flag will
produce ugly artifacts where AA blending should happen. Fix one
bug and the other appears, and vice versa.
This can be tested with the example evas-map-aa and adding an
alpha channel to cube1.png (with gimp for instance) but manually
setting alpha to 0 in the code. Weird stuff will happen (try
playing with the map and pressing I to switch to/from image mode).
Idea originated from Cedric the b0rker.
This is a big fat search-and-replace commit.
This commit also introduces space changes... Sorry for the mix.
NOTE: This commit may have one side effect as there was some very
dubious code chaning the dst image's alpha flag in the
Gfx get functions. Logically this didn't make sense (at
draw time the dst alpha should already be well defined),
so it should be safe.
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
Hermet Park
Jean-Philippe Andre
Carsten Haitzler
Jaeun Choi
ChunEon Park
Leandro Pereira
Vincent Torri