if yuou use 709 instead of 601 yuv (ycbcr) evas will just be wrong and
use 601. this fixes that and implements 709. it also fixes a scaling
bug for yuv in the gl engine. no one noticed but me, so i won't call
this a bug fix, and it can go into the next efl release - no need to
backport unless it actually bothers peolpe (which it seemingly doesn't)
Summary: This fixes build for aarch64 when TILE_ROTATE is disabled and BUILD_NEON is enabled(it is enabled by default for aarch64 since https://phab.enlightenment.org/D2309).
Reviewers: cedric, raster
Subscribers: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2498
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
In GCC 5.1 arm_neon header for aarch64 was changed. It is not possible anymore to silently cast uint64x1_t to int.
So replace cast with proper getter function to avoid following error:
lib/evas/common/evas_convert_color.c:50:18: error: incompatible types when assigning to type 'DATA32 {aka unsigned int}' from type 'uint64x1_t'
nas += vpaddl_u32(vpaddl_u16(vpaddl_u8(cmp)));
Reviewers: raster, cedric, devilhorns
Subscribers: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2443
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: NEON intrinsics can be built both for armv7 and armv8.
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2442
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: NEON intrinsics can be built both for armv7 and armv8.
Reviewers: raster, cedric
Subscribers: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2441
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: NEON intrinsics can be built both for armv7 and armv8.
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2440
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
NEON intrinsics can be built both for armv7 and armv8.
There were no NEON variant for this function, so it was added with all copies to init function.
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2417
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Use vceqq and vbsl instead of twice as much vmovl and vadd instructions.
Replace vaddq_u8 with vaddq_u32.
This allows NEON code to behave exactly like C version.
Reviewers: raster, cedric
Reviewed By: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2361
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Use vceqq and vbsl instead of twice as much vmovl and vadd instructions.
Replace vaddq_u8 with vaddq_u32.
This allows NEON code to behave exactly like C version.
Reviewers: cedric, raster
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2362
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Add new define, BUILD_NEON_INTRINSICS to control whether NEON inline code or
NEON intrinsics should be built.
GCC NEON intrinsics can be built both for armv7 and armv8. However NEON inline
code can be built only for armv7.
@feature
Reviewers: raster, stefan_schmidt, cedric
Subscribers: cedric, stefan_schmidt
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2309
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
When processing random data result of this function differs from C variant in more than 50% cases.
This difference is due to alpha calculation, in C code :
alpha = 256 - (*s >> 24)
in NEON:
"vmvn.u8 q4,q0 \n\t"
// ie ~(*s>>24) === 255 - (*s>>24)
We cant just add "1" as overflow will occur in case (*s>>24) == 0 (we use only 8 bit per channel in vector registers)
So here is the solution:
copy *d right before multiplication and add it to the result of it later.
Same approach as in D455.
Reviewers: raster, cedric, stefan_schmidt
Reviewed By: cedric
Subscribers: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2308
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Make sure not to sample the mask image outside its boundaries.
This is a series of last resort checks. I can not reproduce the
crashes but know they have happened.
I used EINA_UNLIKELY more for clarity than for compiler optimizations.
As C version,
It increase alpha value by 1 to avoid loosing of the remains while it divides
values. Neon version does same technique to make same results.
This patch reduces power consumption by around 18mA in certain scenarios
(music player list scroll, my files sound list scroll), making
evas_common_convert_argb_premul() ~60% faster (6.2msec->2.6msec).
Take music-player application, make 100 copies of the standard
Over the Horizon” song, scroll up and down to see those
downscaled-from-720x720 thumbnails enter and leave the screen.
Every time a list item enters the screen, the image is re-read
(as evas image cache is not large enough to store more than two
pictures of that size), and one call of _common_convert_argb_premul()
occurs, taking ~6.2msec (which is not much compared to ~60msec
spent in libpng->libz (the biggest bottleneck here),
but still noticeable).
A similar power consumption improvement is observed during
scrolling sounds list of the same files in My Files application
(just with idle level ~100mA lower).
We also checked the new code to be correct on random input data.
all tests are performed based on tizen device.
Signed-Off-By: Artem Dergachev <dergachev.a@samsung.com>
prev logic increased the alpha channel by 1 so the unpremul resulted in the color got too diff from the origin.
We can't avoid losing the rest values while dividing values in premul/unpremul()
but this will recover the value better closed to origin value.
previously, it had the remaining value issues on blending computation.
The blending color result was in correct.
Signed-Off-By: Vladimir Kuramshin <v.kuramshin@samsung.com>
This is for now just a small experiment. It was based on the experiment made
with OpenMP. I prefered to only use Eina here as we have already all the infrastructure
to do this nicely and simply. As a result I get a 65% speed improved on average for
the involved scaling operation. The secondary CPU is on my laptop running with a load of
75% percent. I don't have right now the time to do power consumption analysis, but I
think it shouldn't be to bad. I am also not throwing more core at this as we are not able
to use the second core at its max already, so additional core may result in a bigger
energy loss without enough gain.
A rare case of garbage data would happen if smooth scaling
was called with a mask and 1:1 scaling. Use the proper
render_op to COPY for the first pass.
@fix
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).
The selected op func was not performing the correct operation,
thus producing rendering artifacts. These functions should not
be used anywhere except in case of masking... which was not an
available option earlier.
It was doing (wrong):
dst = interp(mask, src, dst)
Instead of (correct):
dst = dst + (1 - mask) * src
NOTE:
This commit also disables MMX, SSE3 & NEON implementations of
pixel_mask blend operations, since they are also broken.
Work done by Jaeun Choi, rebased & squashed by jpeg.
This commit introduces changes to the low-level draw functions
of the SW engine considering the existence of an alpha mask image.
Features:
- Font masking (TEXT, TEXTBLOCK),
- Rectangle masking,
- Image masking (all image scaling functions should be handled).
The mask image itself is not yet set in the draw context (see
following commits).
@feature
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
So I've discovered some weird output values after drawing
some text. The destination alpha would become 0xFE even
when the back buffer had a background with 0xFF alpha.
Example:
Dest is 0xff00ff00 (green).
Color is 0xffffffff (white).
Current font alpha is 170 (0xaa).
--> Output was 0xFEaaFEaa instead of 0xFFaaFFaa.
This is because of some slightly invalid calculation
when doing the font masking (mtab[v] = 0x55 above).
Indeed, MUL_256 takes alpha values in the range [1-256]
and not [0-256] as was assumed.
This should ensure that the difference between the original
pixel value and the rle4 encoded one is <= 8.
The previous fix was a bit stupid as it was not taking into
account the conversion a4 to a8 (which is a8 = (a4 << 4) | a4).
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
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.
Also, mark some functions with a FIXME as they look just wrong.
COPY_REL is never used...
MMX and NEON optimizations should be implemented for COPY MASK+COL.
Summary:
Without compilation will fail on :
error: unknown type name 'pix_type'
error: expected identifier or '(' before 'else'
Applies to efl-1.11.0 and later
Bug: https://phab.enlightenment.org/T1620
Bug-Tizen: PTREL-737/part
Change-Id: Idbcb442803ed6559698b2a371d1d6c584ec053e0
Signed-off-by: Philippe Coval <philippe.coval@open.eurogiciel.org>
Test Plan:
gbs build -P "profile.tizen_common_armv7l" --arch armv7l --include-all
@fix
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1399
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Now, the evas loader is supposed to advertise the actual border
size in case of compressed texture formats.
The only case where the border was non zero was ETC formats,
from the TGV loader, so I think we don't need to keep the
previous behaviour (auto-calculate borders for ETC).
ecore_evas_convert: Add -e/--encoding option
This uses directly the encoding parameter.
For now, used only by the TGV saver, but there is no other way
to specify between ETC1 and ETC2. And we don't have a mixed ETC1+2
mode (yet).
@feature
"f<color=#f00>i</color>f" could cause textblock to crash. It doesn't
crash anymore. It doesn't render the colours correctly either, but at
least this is the first step.
This is the start of fixing T1308
@bugfix
Summary: The comparison dc with NULL is not necessary. So remove the unnecessary conditional expression.
Reviewers: Hermet
Reviewed By: Hermet
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D908
The TGV file format is specifically created for Evas. It is designed to allow
region decompression and parallele decompression with a fast path for GPU that
do handle ETC1 compression. Plan for adding other compression method will come
later.
configure: fix prerequisite header issue
Summary:
in some platforms like openBSD <sys/socket.h> must be included before
net/if.h
the canonical way to ensure that with autotools is by providing that
fourth directive.
evas: use MAP_ANON instead of MAP_ANONYMOUS
Stupid unpredictable standards (or not so standard).
MAP_ANON exists and is defined almost anywhere unlike MAP_ANONYMOUS
Let's use that for portability's sake (they are practically identical
anyway)
Reviewers: raster, cedric
Reviewed By: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D616
Signed-off-by: Cedric BAIL <cedric.bail@free.fr>
This happens with many texts. The issue occurs when the width of the
last char is larger than it's advance. Before this patch, we didn't the
width into account when calculating width, thus causing clipping issues
in some cases.
in all other convert functions, dst_jump is provided in pixesl and
multiplied by the number of bytes-per-pixel either explicitly or
implicitly by using a different type for dst pointer (DATA16,
DATA32...).
As in 24 bits we use DATA8 we must explicitly multiply dst_jump by 3.
The structure should not be changed, despite the union modification.
I am renaming for consistency with older branches that had a mask
field in RGBA_Image. Also, the mask.data or data8 is really just
a way to avoid casting between DATA8 and DATA32 (and it shows
clearly what kind of data you are dealing with).
_op_blend_pan_mas_dp is just a duplication of the code in
_op_blend_pas_mas_dp. Remove the extra copy of the code and use a define
instead; this is what the SSE3 code already does.
Summary:
There's nothing SSE3-specific about that macro, let's use a more generic name
for it. Since that's just a generic macro, we can also allow non-SSE (eg.
NEON) code to use it if they want to
Reviewers: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D528
Well, raster did some great job at optimizing font draw... but only
to RGBA32 targets. In this font effects case, we also want to render
text on ALPHA buffers.
For now, reuse the existing alpha blending & glyph decompress
functions. It's MUCH easier, and works. Definitely slower than
decompressing on-the-fly and optimizing everything. But for now,
this will not even be the performance bottleneck in an effect
(blur will be a lot slower).
Evas is an RGBA only engine, BUT we also use some alpha masks,
especially in the font rendering pipeline.
This commit adds basic support for alpha buffer operations
(blend and copy).
RGBA_Image can then point to either alpha-only data, if
its colorspace is grey.
This is a long awaited feature that has been requested years ago.
Fontconfig finally added the support needed to make it happen, so here
it is.
I added a fontconfig query to look for similar fonts in case we loaded a
font from eet/edje/file(no fontconfig). This now works quite well.
Still missing: if you load a bold/italic/whatever font directly (set the file)
without putting ":weight=bold" you will not get run-time emboldenment if
only non-bold fonts are found.
This unfortunately depends on very recent fontconfig version (#ifed out
when unavailable), so only people with fontconfig >= 2.11 will enjoy
this feature.
This function does the following operation:
COPY pixel x mask --> dst
But it wasn't iterating over the source. So it was repeating
the value of the first pixel over and over again.
Is this even used anywhere? RGBA + alpha mask function!?
Summary:
When processing random data result of this function differs from C variant in more than 50% cases.
This difference is due to alpha calculation, in C code :
a = 256 - (c >> 24)
in NEON:
"vmvn.u8 q7,q6 \n\t"
// ie (8 bit)~(c>>24) === 255 - (c>>24)
We cant just add "1" as overflow will occur in case (c>>24) == 0 (we use only 8 bit per channel in vector registers)
So here is the solution:
copy *d right before multiplication and add it to the result of it later.
This makes the function slower by 20-30% but it is still at least 2 times faster then C code.
Reviewers: raster
Differential Revision: https://phab.enlightenment.org/D455
this changes the internal encoding of font glyphs in evas to use 4bit
uncompressed if small, or 4bit rle (run length encoded) if larger.
this caves at least 50% of memory on fonts - and more if bigger. with
large fonts (40-80pixel size) we can save in the region of 80% of
memory used for glyphs. this also happesn to allow speedups in
rendering too.
We do have mmap provided by Evil, but there is no implementation yet of
an anonymous map support. Also it is not clear how the memory system of
windows does actually work, so not sure this optimization is relevant
to windows at all. Thus we disable it for the time being and unbreak
the windows support.
- cherry-pick me -
Summary: evas_scale_smooth would not compile with BUILD_NEON set
Reviewers: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D424
Summary:
_op_blend_mas_c_dp_neon rework:
main loop now process 4 pixels per iteration
fast path when *m == 0
Reviewers: raster
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D418
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
stable release - cherry-pick me!
there way a problem with software rendering - it rendered some areas
more than once per frame due to overlapping rectangles. it also had
more rectangles to cover the same update area that it should have had.
this fixes this.
Perhaps they are insane, but as the comments imply it defines
USE_HARFBUZZ which is needed afterwards. You just broke everything. I
know it's a mess there, but it's a mess that works. Your change doesn't.
This reverts commit d4b9e3b287.
Try to reconnect to cserve2 if the socket connection was lost.
Resend some messages if necessary.
Images reload seems to be working.
Actually, the images don't change over time, so the clients just
keep the previous references to their images.
FONT RELOAD IS NOT WORKING:
- Crashes
- Invalid glyph data
- Infinite loop in _glyph_map_remap_check()
Root cause:
When new glyphs are requested from the server, they are added to
the mempool. So it is necessary to remap the font.
Unfortunately, in case of server reboot, we did not keep the mempool
so the old glyphs that were not requested again will not be valid.
cserve2 does not support animated Gifs, as the animated icon
logic doesn't match cserve2 logic.
Also, there is probably no need to cache these into shared
buffers anyways :)
Solution: fallback to normal cache (and delete current entry in
the client)
Let's reuse the logic from scalecache and call cserve2
functions when the scalecache should be used.
So, now, cserve2 server will not scale any image... This is
too computationally intensive for the server's main thread.
This is not optimal but makes a hell of a lot more sense for
the moment. (since cserve2 manages the SHM segments)
this fixes https://phab.enlightenment.org/T182 as it is an issue with a
surface alloc overwriting an already allocated surface entirely inside
the general software image infra.
This add finally support for JPEG 2000, but be aware that libopenjpeg
is very badly managed. There is currently only version 1.5.x that does
provide the right files, is usable by a third party and portable. You
can seriously forget any other version.
This issue cause non-letter RTL characters not to be detected as RTL
which in turn turned off bidi for those strings.
Example broken text: <RLM><LRO>[PAS<RLO>[--DES<PDF><PDF>.
Thanks to Yakov Goldberg for reporting this issue.
as pointed out by y.usishchev@samsung.com - this code is copy & paste
badness, but the compiler optimizer fixed it up already, so it made no
difference in real life.
Since we locked the font_draw mutex earlier, we should unlock it
before we return.
NB: Fixes Coverity CID1039382
Signed-off-by: Chris Michael <cp.michael@samsung.com>
evas_common_font_int_cache_glyph_get), then we should free that
allocation when we have an error.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Fixes a memory leaks in evas_common_convert_yuv_42* and actually makes
these functions more useful. It's a win-win.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
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 reverts commit 9473c4a9a5.
This commit is not correct. It just goes through every font in the
fontset, which is usually all the fonts in the system and tries to get
their ascent/descent and by that getting the max ascent/descent. This
won't work nicely.
The solution is to properly fix textblock, if you think there's
something lacking (I.e in the same way I did text).
However, my changes did not change previous behaviour, but were just
wrappers, so I don't see why extra changes would be needed. Please
elaborate.
I'm reverting this because:
1. I don't think it's correct.
2. It severly broke e in some cases (reference:
http://www.enlightenment.org/ss/e-51b5d5e98cd387.04568822.png ).
This is an astonishing bug, I wonder since how long it has been there. It
is basically due to the use of void * and a wrong cast. Type checking is
clearly useful, let's use it more !
CEDRIC... it WAS YOU!... YOU BROKE ETHUMB!... i was.. RIGHT! :) well
done. your borking skills are pretty good. :) you broke load opt
downscaling for jpegs in general.. it just happened to turn up in
ethumb.
Goal is to be able to remove all internal Evas call from inside all
loader module. To do so we are going to open and hold a reference to the
file from outside of the module, read the header, create the image data,
load the data, close that reference.
Once that done, the next step is to let the file remain open as soon as
the filename/key is set and add an API to set an Eina_File directly. This
way edje can maintain the same file open as it use for an edje object,
keeping things in sync and avoid rendering glitch during update.
If query at x coord, which points to rigth half of LTR char,
next position will be returned. The same for left half of RTL char.
Signed-off-by: Yakov Goldberg <yakov.g@samsung.com>
This new engine function will only be used in software generic for
now - since it's the only engine used with the async render.
This function has been introduced in order to avoid growing thread
command queue too much to draw a text_props at a time on render calls
from textgrid objects.
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 82832
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 is intended to preserve old behavior now that we have
evas_common_font_draw_cb() to handle both sync and async callbacks.
However, we need to check where why we end up with no glyphs in a
text_props even after calling evas_common_font_draw_prepare().
SVN revision: 82664
This sould bring back a little bit of text rendering performance, while at
the same time decreasing memory usage and fragmentation.
Patch by: Leandro Pereira <leandro@profusion.mobi>
SVN revision: 82660
Fixed queue cache handling to let enqueue and process happen at the same
time, even though this is not our use case yet. This also solves a race
with the assignment of cache variables outside the queue lock and
remembers to free the cache when shutting down.
SVN revision: 82296
Stefan Schmidt
Carsten Haitzler
Yury Usishchev
Cedric BAIL
Tom Hacohen
Jean-Philippe Andre
ChunEon Park
Youngbok Shin
Daniel Zaoui
Jaeun Choi
Bogdan Devichev
ChunEon Park
Mike Blumenkrantz
Philippe Coval
Wonguk Jeong
Jaehyun Cho
Matvey Konovalov
Cedric BAIL
Cedric BAIL
Alex-P. Natsios
Boris Faure
Gustavo Sverzut Barbieri
Snacker (Vladimir)
Daniel Kolesa
Albin Tonnerre
Jihoon Kim
Nick Reed
Daniel Juyung Seo
Cedric BAIL
Jean Guyomarc'h
Vincent Torri
Ulisses Furquim
Chris Michael
Daniel Willmann
Sebastian Dransfeld
Jiyoun Park
Yakov Goldberg
Igor Murzov
Ulisses Furquim
Paulo Alcantara
Leandro Pereira
