Summary:
The image.data is set to null by evas_common_rgba_image_unload_real.
After this point the cache->usage does not count cache_entry.w and h value when
evas_gl_common_image_free calls evas_cache_image_flush.
So the cache->usage increases just around 300. If the cache->limit is 4194304,
then the cache could have around 1398 items. This would be fine.
But each items hold eina_file, and the cache does not count eina_file size.
If the file size is 326352, then a process could use 456527385 bytes.
So this patch set make the cache->usage count eina_file size.
This would be better option than https://phab.enlightenment.org/D7029
Reviewers: Hermet, jypark, cedric
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7030
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
Summary:
current copy color function has problem sometime on a arm neon environment.
inline asm code makes crashing problem.
so that this patch replace the asm code with a function which is a part of pixman project.
Reviewers: cedric, Hermet
Subscribers: kimcinoo, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6922
Summary:
this is more or less a dead project, having not been actively developed
in over 2 years and instead forcing people to expend more time and energy
to keep it compiling across refactors
fix T7227
Reviewers: stefan_schmidt, Hermet, ManMower, devilhorns
Reviewed By: Hermet, devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7227
Differential Revision: https://phab.enlightenment.org/D6878
Summary:
these separate inits and shutdowns make it impossible to effectively control
ecore's lifetime which makes evas_shutdown unreliable as objects may be
destroyed at any point
ref T7052
Depends on D6475
Reviewers: ManMower, devilhorns
Reviewed By: ManMower, devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7052
Differential Revision: https://phab.enlightenment.org/D6476
this resolves some invalid read/write operations between threads without locking
and also attempts to improve thread-related behavior after fork() calls
ref T7027
Differential Revision: https://phab.enlightenment.org/D6370
Summary:
the previous patch which improved this code for x86 archs broke compiling
for non-x86 and, coincidentally, for windows builds on x86 due to some
unusual #ifdef blocks
this attempts to restore handling on non-x86 and adds additional #ifdefs for
functions which did not build on windows due to removed code
ref 6b1ab3cd9c
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7062
Differential Revision: https://phab.enlightenment.org/D6368
Summary:
To determine if a system supports SIMD instructions, the cpuid facility
should be used. However, for 15+ years EFL has been trapping SIGILL,
then attempting to execute these intstructions.
Continuing after SIGILL is explicitly undefined behaviour and can never
safely be relied upon - it is possible the CPU will respond to the
unknown instruction in an upredictable way and the program will not
continue correctly. Even if it hasn't caused problems before, there's
no reason to believe a processor released in the future won't behave
differently.
Lately we've had a couple of bug tickets where SIGILL appears to cause
problems at a system level as well, but there seems little point in
chasing those problems down as we shouldn't even be doing this in the
first place.
ref T6711
ref T6989
We still rely on SIGILL in a few configurations where eina_cpu doesn't
know how to query features properly (powerpc, sparc, and non linux
ARM configurations). Hopefully someone with expertise on those
platforms can follow up and we can remove this entirely.
Note: MMX2 appears to not really be a thing, and is instead provided by
both 3DNow! and SSE. We already conflate it with SSE in other parts of
evas, so I've just used SSE here to test for its presence.
Depends on D6313
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T6989, T6711
Differential Revision: https://phab.enlightenment.org/D6314
since this can take an extension as well as a file path (extension
being .gif or .jpeg etc.) it would skip if passed a small extension
only (5 chars or less). fix and this fixes e's thumbnailing too for
some files.
@fix
Summary:
The fribidi couldn't reorganize paired brackets (Ex. '(', ')')
when there is RTL + LTR text. According to TR9(http://www.unicode.org/reports/tr9/),
it has to be shown properly without LRM or RLM.
Also, from the fribidi 1.0.0, fribidi_get_par_embedding_levels() was deprecated.
It is replaced with fribidi_get_par_embedding_levels_ex() which is including
paired brankets rules from TR9.
@feature
Test Plan:
1. Create a elm_entry.
2. Set a text by calling text_set.
elm_entry_entry_set(entry, "مرحبا Hello (40)");
3. Run and see the results.
- Without this patch or fribidi 1.X.X, it will show text like this...
"(Hello (40 مرحبا"
- With this patch and fribidi >= 1.0.0
"Hello (40) مرحبا"
Reviewers: raster, cedric, herdsman, woohyun
Reviewed By: herdsman
Differential Revision: https://phab.enlightenment.org/D5921
Old version algorithm was imperfection a bit, quality was poor at some specific
degrees, specifically, when pixel increment pattern on the diagonal lines is
unstable.
This revised version was better than old one even source code is much cleaner
and simpler.
See belows.
*NonAA vs AA:
https://ibb.co/bCNfMc
*Compare the worst case aa in the old version:
https://ibb.co/bEJsZx
*Test video:
https://youtu.be/Wn20Tym5lfg
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
Evas map anti-aliasing haven't worked at all if the smooth scaling were disabled.
evas map rendering has a lot of corner-cases, previous call-position was wrong,
(by mistake maybe) shouldn't be in a certian case.
Let aa post-processing function be performed in universally.
we can't sensibly use things like massif to track memory if we bypass
itr with mmaping -1 fd anonymous memory... so if built with valgrind
support and running under valgrind, use malloc/calloc and free so
these tools actually do something useful for these bits of memory.
Public symbols were defined internal to Evas/Elementary on macOS, making
the link of external modules unfeasible.
- EAPI was messed up by an invalid inclusion of evas_text_utils.h, making
some symbols private instead of public.
- A similar issue was present in evas_font_draw.c, where the symbols
were directly imported without the proper definition of EAPI.
- Elementary.h did include some eo-generated headers, but for windows
only. It should not been restricted to windows, as it allows to export
symbols to external modules.
Fixes T6448.
Using filters I end up in situations where this function returns NULL
and all hell breaks loose. I guess the spinlock is what makes this
possible (race condition).
@fix
Summary:
Parameters w and h are declared as int for evas_common_rgba_image_from_data
and evas_common_rgba_image_from_copied_data in evas_image_data.c. This
does not match the prototypes in evas_image_private.h which declares them
unsigned.
Original report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748026
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5540
Build failed with LKI not found, as a symbol, but it's a macro.
Copy & pasted from evas_common_private.h
How can this work on one platform and not another? I don't get it...
Summary:
dev branch : devs/subhransu/font
The Final goal is to move the evas_font module to ector so that both ector and evas can reuse the code.
make the api simple so that sam eapi can be used by evas_textblock and ector text.
This is the 1st stage to achive that gola, first remove the evas internal dependancy as much as possible before moving to ector library.
Reviewers: jpeg, raster, herdsman, cedric, id213sin
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5419
Summary:
A new parameter "width_offset" was added to
evas_common_font_query_last_up_to_pos() internal function.
But, internal documentation was not updated.
So, it adds a simple description for the new parameter.
Test Plan: N/A
Reviewers: jpeg, cedric, herdsman, shilpasingh
Differential Revision: https://phab.enlightenment.org/D5035
This is modifying how a rarely used environment variable that sets the
DPI used for font sizing is parsed. The previous form remains valid, of
course. Note that EFL tends to use "scaling" instead of this DPI. The
font DPI is useful for me to open up a terminology window with almost
the same size as my IDE's code viewer.
Use case:
export EVAS_FONT_DPI=95x94 terminology
Note:
I still don't get a 1:1 match with Qt's rendering, and in fact
94x95 works better than what 95x94 (which is reported by xdpyinfo).
Interesting though :)
@feature
Summary:
There is no effect of assingning a variable while clean up.
@fix
Reviewers: raster, cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5272
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
Variable assigned is not used anywhere else, making it unused.
@fix
Test Plan: Na
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5263
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The incomplete reset (array to NULL but max not reset) triggers errors
in evas_thread_queue_append() where eina_inarray_grow() returns NULL.
This shows up in:
CK_FORK=no elm_suite
@fix
Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
Summary:
INHERITED script unicodes are only meaningful when it comes
after the previous unicode from same font.
Even if there is no glyph for the INHERTED script unicode from current font,
don't search other font for loading the unicdoe as first unicode
of next item. It will be meaningless.
@fix
Test Plan:
Check the following Emoji sequence with an emoji font
which does not have variation selector glyphs.
{ 0x1F3F3, 0xFE0F, 0x200D, 0x1F308 }
Reviewers: raster, cedric, herdsman, jpeg, woohyun
Reviewed By: herdsman
Differential Revision: https://phab.enlightenment.org/D5156
Summary:
When harfbuzz is enabled, _content_create_ot() function will be used
for shaping. If evas_common_font_int_cache_glyph_get() failed in some reason,
it never proceed gl_itr until the end.
It can cause weird rendering result. Because, all of gl_itr after the failure
can't have proper x_bear, y_bear and width.
@fix
Test Plan: N/A
Reviewers: raster, cedric, herdsman, jpeg
Differential Revision: https://phab.enlightenment.org/D5154
Summary:
Assigning a result of integral division to a double type variable is
not useful for next division calculation. For more accurate calculation,
it needs to be casted to double before doing division.
It does not fix some bugs. It was reported by a code quality advisor.
Test Plan: N/A
Reviewers: raster, cedric, jpeg, herdsman, eunue
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D5069
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
This reverts commit 9368eedd35.
The release is out so we can revert this bandaid again. In the hope to
find the real culprit and solution before the next release.
Currently, elementary programs crash on termination on macOS (seems
Sierra-specific). This is very nasty, looks like deep memory corruption...
Without valgrind (or like) support on Sierra, it is difficult to
pinpoint the origin of the problem.
Due to the imminient release, and after discussion with @stefan, this
kludge will allow the release to happen.
This commit MUST be reverted just after the release, so we don't
blindfold ourselves!
Ref T5245
Summary:
There are many requests to add a new feature for handling horizontal align
according to current locale. For example, in RTL locale setting,
users want to see right aligned text for every list's item.
Even if some of list's items only contain LTR characters!
It is useful for the needs.
@feature
Test Plan: N/A
Reviewers: herdsman, tasn, woohyun, raster, cedric
Reviewed By: herdsman, raster
Subscribers: z-wony, jpeg
Differential Revision: https://phab.enlightenment.org/D4664
This is needed by dmabuf engine fallback when it realizes it locally
allocated a buffer, has been rendering to it, but the compositor can't use
it.
So the engine copies its buffer contents into a new wl_shm buffer and
continues from there - however we need to make sure the async renderer
has finished first, so we don't copy a partial buffer.
This allows us to block for all previously submit actions in the render
queue to complete.
Summary:
Rounding the sum of glyph's advance could cause inconsistency of
each glyph's positions. When Evas enables Harfbuzz library,
Each glyph's position has to be handled by only nearby glyphs.
But, currently, totally unrelated glyph's advacne could change
other glyphs positions.
ex) 1. "connect."
2. "Tap here to connect."
You can see different gap between "c" and "o" of word "connect".
It should be same even if there was a different text before the word "connect".
@fix
Test Plan: N/A
Reviewers: raster, herdsman, jpeg
Reviewed By: raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4782
This is an attempt at refactoring the filters code so I can
later implement GL support. This patch adds a few extra changes
to remove avoid calling functions of libevas from the software
engine: use the draw functions from static_libs/draw rather
than evas_common APIs.
The only purpose of this commit was to allow efl 1.19 to be
released on macOS wothout crashing on termination. Time to revert
it and see that we can find a real fix for the next release.
This reverts commit cd5e755951.
ref T5245
There are reports of crashes when y < 0. This case seems
abnormal in case of filters, as I don't know how to reproduce it,
but it's happened.
Thanks Youngbok Shin for the report.
@fix
Summary:
If the last item before ellipsis item has bigger width than its advance,
evas_common_font_query_last_up_to_pos() function can find wrong ellipsis position.
When Evas finds a position for non last item, Evas must care about additionally
available space for glyph's width of the given x position.
ex) the last item's glyph before ellipsis item has a tail to draw above the ellipsis item.
@fix
Test Plan:
Test case will added as comment.
(Becasue of font license problem.)
Reviewers: herdsman, raster, jpeg, woohyun
Subscribers: cedric, Blackmole
Differential Revision: https://phab.enlightenment.org/D4727
Currently, elementary programs crash on termination on macOS (seems
Sierra-specific). This is very nasty, looks like deep memory corruption...
Without valgrind (or like) support on Sierra, it is difficult to
pinpoint the origin of the problem.
Due to the imminient release, and after discussion with @stefan, this
kludge will allow the release to happen.
This commit MUST be reverted just after the release, so we don't
blindfold ourselves!
Ref T5245
If GL context is free'd before processing font shutdown,
textures for emoji glyph's GL images will be free'd without clean
up its GL images. It causes eina mempool infinite loop issue when
emoji's GL images are free'd in shutdown process.
So, the patch will make a list for emoji's GL images in context and
clean up them when the context is free'd. Just like font textures in
context.
@fix
Differential Revision: https://phab.enlightenment.org/D4695
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Summary:
SETUP_LINE_SHALLOW and SETUP_LINE_STEEP are each identically defined
(except whitespace) in evas_line_main.c
Reviewers: cedric, jpeg
Subscribers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4681
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>
Carsten Haitzler
Shinwoo Kim
Marcel Hollerbach
Hermet Park
Wonki Kim
Chris Michael
Mike Blumenkrantz
Derek Foreman
Youngbok Shin
Vincent Torri
Jean Guyomarc'h
Jean-Philippe Andre
Pawel Aksiutowicz
Ross Vandegrift
subhransu mohanty
Cedric BAIL
Godly T.Alias
Subodh Kumar
Jaehyun Cho
Marcel Hollerbach
Bryce Harrington
Stefan Schmidt
Jiyoun Park
Haegeun Park
Hermet Park