it's a warning one way or another so reduce noise with a harmless case
as passing in a pit ro a 32bit type is more restrictive than the ptr
it accepts (an 8bit type)
so a little perf fun shows malloc/free/realloc/etc. are, combined a
reasonable overhead. this reduced malloc overhead for draw contexts so
whne we duplicate them or create new ones, we re-use a small cache of
8 of them to avoid re-allocation. just take the first one from the
list as it really is that simple. mempool would not have helped more
here and cost more overhead.
@optimize
In gl engine, image objects try to unload image's pixel data after creating or updating the texture.
but image entry's reference is still 1, it is added to the pending_unloads list,
and it is cleaned when evas render function.
If elm image use preload feature, preload_done flag is true, so this image data cannot be removed from
pending_unloads list, it cause memory leak.
I think it is better to free image's pixel data in evas_cache_image_unload_data,
(not add to the pending_unloads list)
but it it complicated to modify.
so I'll remove the code to check preload_done flag in evas_common_rgba_pending_unloads_cleanup function.
this flag check was added because of gl preloading, but now gl preloading feature is disabled.
this flag is related with https://phab.enlightenment.org/D2823
I tested photocam, but crash doesn't occur anymore, even though removing flag check.
to date if you use async preload we still load the header
synchronously and this can be horrible especially with generic
loaders. there is no way to farm this off to the preload thread. now
there is. youhave to set it as a skip head load option before doing a
file_set AND you need to issue a preload ... but now it's possible.
@feature
i found evas_common_draw_context_apply_cutouts() was procsessing 300+
cutouts and as it's O(n^2)/2 to try and merge adjacent rects for
cutouts this really performs like complete junk. we apply cutout rects
a LOT. this is not the best solution, but it's quick and much faster
than doing the clipouts which drop framerate to like 1-2fps or so in the
nasty case i say (tyls -m of photos in a dir with a 2160 high
terminal).
this figures out the target area to limit the count of rects
significantly so O(n^2) is far far better when n is now < 10 most of
the time. and for the few operations where it's a high value this now
uses qsort to speed up merges etc. etc.
@optimize
this doenst change functionality but just cleans up the file
whitespacing and formatting and removed commented out junk, 80 column
wrapping/overflow etc.
We have an issue that eina_thread_queue msg isn't delivered properly on win32.
That occurs broken image drawing in case of non-smooth scaling.
I disabled this feature on win32 because scale_sample_draw is gonna be rarely used
since async rendering introduced.
elm_suite would crash when CK_FORK=no is set, because evas was
badly initializing or shutting down. Note that elm_suite still
crashes with CK_FORK=no but valgrind doesn't complain.
Summary:
In case of thread creation failure, shutdown logic will be stuck.
To prevent stuck, set exit variables to make thread_shutdown working
even if init fails.
Also modify init logics to return init result to a caller.
Reviewers: jypark, woohyun, cedric, jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4411
Note (@jpeg):
I have modified the patch just a little bit.
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Compiling on rpi3 indicated that there are some unused variables in
the neon codepaths for several evas op functions. This patch just adds
EINA_UNUSED to the function parameters where needed.
NB: No functional changes
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Compiling on rpi3 using neon indicates that 'alpha' and 'tmp'
variables are unused. Reading through the source confirms it, so
remove them.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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.
so bu5hman pointed out a compile warning from clang that
{ 0x20000, 42711, EVAS_SCRIPT_HAN },
has 42711 exceeding a signed short. true. so this should be an
unsigned short. but this drew me to the fact the whole array could be
shorter by packing this short with the style memeber after it making
them pack into a nicely aligned 4 byte chunk next to the start unicode
value before it, thus chopping 1324 bytes off this table. even worse
the 8192 entry fast table above is using a full 32bits per entry where
they data they store is not even exceeding 7bits, so move this to an
unsigned char saving another 24k. this should reduce cache misses and
memory footprint and binary footprint of the evas .so files etc.
@fix + @optimize
Ref T4623
v40 bytecode interpreter is official as of freetype 2.7.
The results don't look so good at the moment. The text looks and glyph
positioning seem worse than they were with the previous v35 interpreter.
So, in the meantime we'll keep using v35, just so everything looks
normal again.
Although the v40 is relevant since around 2.6.3, I rather not do any
FREETYPE_MINOR checks in this patch, because distributions might ship
previous versions with the other (v38) interpreter enabled.
We've been pinning the render thread for every EFL process to core 0.
This is a bit silly in the first place, but some big.LITTLE arm systems,
such as exynos 5422, have the LITTLE cores first.
On those systems we put all the render threads on a slow core.
This attempts to fix that by using a random core from the pool of fast
cores.
If we can't determine which cores are fast (ie: we're not on a
linux kernel with cpufreq enabled) then we'll continue doing what we've
always done - pin to core 0.
We've been pinning the render thread for every EFL process to core 0.
This is a bit silly in the first place, but some big.LITTLE arm systems,
such as exynos 5422, have the LITTLE cores first.
On those systems we put all the render threads on a slow core.
This attempts to fix that by using a random core from the pool of fast
cores.
If we can't determine which cores are fast (ie: we're not on a
linux kernel with cpufreq enabled) then we'll continue doing what we've
always done.
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 brings support for the eo api for external buffers (like
the old data_set / data_get). The new API now works with slices
and planes.
The internal code still relies on the old cs.data array for
YUV color conversion. This makes the code a little bit too
complex to my taste.
Tested with expedite for RGBA and YUV 422 601 planar, both
SW and GL engines (x11).
It's entirely possible that a system doesn't have a cpu 0, so
when we try to pin all our render threads onto processor 0 we
may fail.
This results in some very connfusing build breakage when
edje_cc hangs up because its render thread didn't start.
So, if starting the thread with affinity fails, let's try without
affinity.
(This is trivial to reproduce - just use sysfs to turn off cpu0
after boot.)
@fix
this speeds up downscaling of images by somewhere between 1.8 to 3x
dpeending on case and cpu etc. - this is ONLY for downscaling of an
image buffer betweeb 50% width and/or height up to 100% of width and
height. it's a special case optimization that cuts down the complexity
of the full super sampling filter to just do a bilinear interpolation
which is actually strictly correct for this size range and shouldn't
drop quality. it uses fixed point (16.16) to do the sup pixel sampling.
no mmx/asse or neon, but we could actually easily use it as we do use
mmx/ee and neon in the bilinear upscaler to do interpolation so this
would work here too. it just requires time and effort to make yet 2x
more special cases and use the ASM to do the hard slog here.
@optimize
This is essentially a cleaner redo of ef817f15f0.
Logic should be exactly the same as there, the different is that this
one shares the code between OT and non OT.
Please refer to that commit for more information.
This was not done correctly. This split the code, which is essentially
the same for both OT and non OT. It's the same logic with some minor
additions for OT, so most of the code should be together.
This reverts commit ef817f15f0.
Fixes T4068.
Simply querying the last glyph to determine the width of the glyph sequence
won't always work, as OT can have negative offsets (adjusts the placement of a
specific glyph better).
The solution is to calculate the "max width" of some sequence that will
guarantee us proper width results. The worst solution would be to iterate on all
the glyphs and sum up the max width. This is a bit impractical. Instead, we will
inspect just the "cluster" of the last glyph, if one exists.
This should have no performance impact on trivial cases, and very little impact
on the others.
@fix
some font glyphs are still allocated after tyhe last gl window is
freed which means we can't make current anymore to free textures after
that. this fixes that by flushing gl texture info from the font cache
when the last gl windows are gone.
@fix
We were copying a user defined string into a fixed size buffer
without doing any boundary checks. This commit fixes that.
Also cleaned up similar code that was using hardcoded numbers.
@fix.
Summary:
evas_common_language_from_locale_* functions kept static pointers
inside of its functions. Once these function was called, it was never reset.
It made big problems for harfbuzz and hyphenation. Also, Elementary
provides elm_language_set() API. Then we need to support it fully.
@fix
Test Plan: Test case for hyphenation is included in Evas test suite.
Reviewers: raster, tasn, herdsman, woohyun, z-wony, Blackmole, minudf
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3864
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
Width calculations should consider the x_bear. This has been leading to
inconsistent results between wrapping calculation during layout and the
final formatted size.
Also, we should stop our walk only when exceeding 'x', so changed "<="
to "<".
@fix
Summary:
Previous implementation loaded data from memory first and then checked the borders.
Here I check the borders first as it is for C implementation.
This prevents read of non-accessible memory.
Reviewers: cedric, jypark, Hermet, jiin.moon, jpeg
Reviewed By: jpeg
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D3809
Those APIs should provide a cleaner interface than the
old data_set/data_get APIs, by making sure the operations are
atomic (ie. no need to call size_set, cspace_set and then data_set).
padding/duplicated borders are not supported.
TODO: Implement legacy API on top of the new API, instead of
this quick patch
Summary:
Evas Text, Textblock, Textgrid keeps own language information.
This language information could be vary from the result of setlocale().
Especially, Evas Textblock supports <lang> tag. The language could be
changed in the middle of text. All of these language has to be used
for harfbuzz shaping.
@fix
Test Plan: N/A
Reviewers: herdsman, raster, woohyun, tasn
Reviewed By: tasn
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3628
See T2865.
Since Harfbuzz 1.1.0, terminology displays fonts funnily aligned to
the top. This is apparently because until 1.0.6 the y_offset was
always 0 for all glyphs, but since 1.1.1 the offset is actually
set.
This is a TEMPORARY fix. There might be an underlying issue left
here.
Harfbuzz changed behaviour in this commit:
commit 44f82750807475aa5b16099ccccd917d488df703
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Wed Nov 4 20:40:05 2015 -0800
[ft] Remove font funcs that do nothing
Summary:
It adds evas_object_paragraph_direction_set, get APIs.
The APIs set or get paragraph direction to/from the given object.
It changes BiDi calculations and affect the direction and aligning of text.
It doesn't have any effect to text without Fribidi library.
The default paragraph direction is EVAS_BIDI_DIRECTION_INHERIT.
If dir is EVAS_BIDI_DIRECTION_INHERIT, paragraph direction is changed
according to smart parent object. If there is no smart parent object,
paragraph direction works as EVAS_BIDI_DIRECTION_NEUTRAL.
@feature
Test Plan:
Test cases included to the following files.
- evas_test_textblock.c
- evas_test_text.c
- evas_test_object_smart.c
Run "make check".
Reviewers: woohyun, raster, herdsman, tasn
Subscribers: c, raster, cedric
Differential Revision: https://phab.enlightenment.org/D1690
This function was trying to infer from the LANG env var, though it should
have just queried the locale all along, as the language we want is the
system's text language, and not necessarily the LANG variable's value.
@fix.
Summary:
Move model save/load to common3d.
Here also will be common algorithms and structures which will be used in all loaders and savers.
See task https://phab.enlightenment.org/T2713.
Reviewers: cedric, Hermet, raster, Oleksander
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3030
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Typos, lack of NULL check, excessive sizeof(type) not matching
the object type, no border set, etc... This all lead to a crash
and then no render (with an error message and then without...).
This also simplifies the implicit loading of ETC1 as ETC2 when
supported by the driver.
@fix
Actually copying max is pretty useless and super slow. We usually have something
like 1024 slot in a context, but a very small amount of them are acutally active.
It would be better to actually do some kind of copy on write technique here, but
as Eina_Cow doesn't handle array and we are close to a release, let's be
conservative.
the overhead didnt show up in y tests. do show up with certain
expedite tests. hmmm. last time i messed with region code it was
actually same speed as tiler. bonus was it was fully accurate.
valgrind pointed this one out. we access freed memory when we dup a
context because the context CONTAINS ptrs to things like rects for
cutouts. we didnt dup these. use the proper context dup call (and
properly ref pixman color image too). this was a random bug/crash
waiting to happen and valgrind caught it. suprising it hasnt turned up
before :/
@fix
this optimizes draw ctxt cutouts by skipping small ones and
remembering the last cutout added so it isn't double-added as well as
extending the minimum cutout array to 512 and going up in blocks of
512 instead of 128. also optimize the clipping code a bit more.
this move evas tiler that does update handling to use fully correct
regions using region.[xh]. this also removed old unused regionbuf code
and a bunch of commented out code no longer needed. much simpler now
and easier to maintain.
For script runs that start with an UNKNOWN character, the whole
run was mistakenly identified as script type UNKNOWN.
Also, refactored code a bit for readability.
Fixes T2670.
@fix
i am not sure if this is the odd crash i am seeing, but in theory it
could be. as these crashes are rare it's hard to find and gdb is "too
late" other than telling me the image is freed already by the time we
do an unload.
Summary:
Now Evas gl preload feature is disabled.
But if it is turned on, memory crash occurs.
Because evas_gl_common_texture_upload is not excuted immediately.
Test Plan: EVAS_GL_PRELOAD=1 ELM_ENGINE=gl elementary_test -to "photocam"
Reviewers: raster, cedric, woohyun, seoz, Hermet, singh.amitesh, jpeg
Subscribers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D2823
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
i was runing perf top and noticed that evas_image_load_file_data_eet(0
was being called. in fact - it was #1 on the list of functions being
called. why? it didn't make sense. i found out. just a blinking cursor
in terminology was causing the background to be unloaded and
re-loaded. the new "actually unload" changes for 1.15 made this happen
and thus we kept sucking in new data all the time even if the
scalecache already had the data - and that was the problem.
so now calcecache prepare tells you if you don't have cached data and
if you likely then have to ensure the data is loaded. this cuts down
quite a bit of work.
while i'm at it... we definitely need to clean house on the internals
of evas. a decade+ of features, mess, optimizations needs to be fixed.
i mean really house-cleaned. rewritten clenl;y re-using existing code
where appropriate.
i think this has been disabled for a while. image unloading is broken
- esp with gl enigne as due to async move it was effectively disabled.
this re-enables it. unloading is deferred with a managed list of things
needing unloading and then when any async sw renders are not busy any
more - do the unload then in the mainloop of all pending/flagged
images to unload
@fix
Otherwise there would be conflicts in certain circumstances.
This also requires adding const on many existing functions,
and similar work is necessary in Elementary.
@fix
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>
Carsten Haitzler
Cedric BAIL
Jiyoun Park
Haegeun Park
Jean-Philippe Andre
Chris Michael
Hermet Park
Wonki Kim
Stefan Schmidt
Sungtaek Hong
Derek Foreman
Daniel Hirt
Jean Guyomarc'h
Tom Hacohen
Jean Guyomarc'h
Youngbok Shin
Vincent Torri
Bogdan Devichev
Srivardhan Hebbar
Hosang Kim
Daniel Kolesa
Oleksandr Shcherbina
Yury Usishchev
ChunEon Park
Daniel Zaoui
Jaeun Choi
Mike Blumenkrantz
Philippe Coval