Summary:
by adding a couple extra params to existing functions, we can reuse
existing code instead of copying it around and adding more bugs
no functional changes
Depends on D8846
Reviewers: segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl_rendering
Differential Revision: https://phab.enlightenment.org/D8847
Summary:
this is already a risky call for larger scanlines, so use the clamped value
to further reduce the chance of blowing out the stack
Depends on D8839
Reviewers: cedric, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, #reviewers, #committers
Tags: #efl_rendering
Differential Revision: https://phab.enlightenment.org/D8840
Summary:
the 'y' parameter is not relevant here. this clamping exists solely
to avoid reading outside the bounds of the mask, and 'y' is the scanline
at which to begin the masking
subtracting the mask size here does not make sense: we are attempting to clamp
to the size of the mask in order to avoid buffer over-read, so this means that
we are mapping the maximum y coordinate of the mask (mask_y + mask_h) to be
relative to the clipped y coordinate (dst_clip_y)
Depends on D8838
Reviewers: cedric, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, #reviewers, #committers
Tags: #efl_rendering
Differential Revision: https://phab.enlightenment.org/D8839
Summary:
this was a bit confusing to read since the comparators are not ordered
as expected
no functional changes
Depends on D8837
Reviewers: cedric, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, #reviewers, #committers
Tags: #efl_rendering
Differential Revision: https://phab.enlightenment.org/D8838
u or v go below 0... sometimes. right now i don't know the full path
to there, bute crashes with flat theme when the busy spinner shows
over an ibar icon when you launch... this at least stops that.
this needs hunting in more detail than i'm going to do on my laptop
on the couch...
evas map has used integer coodinate system since it's born,
since object's transition is jiggled, not perfectly smooth.
It's obvious because Positioning must be stepping with integer units
without any subpixel rendering.
Currently, this patch is a sort of preparatory to improve this,
only valid for high-quality evas map (smooth + anti-aliasing)
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
the tiles rotator is faster no matter what. this will fix D8099 by
movoing to tiled rotation and nuking the neon code and we end uop
being faster anyway in all cases.
@fix
as indicated by the accompanying FIXME, the byte ordering is inverted
for big endian so this should be #ifdef-ed
Reviewed-by: Chris Michael <Christopher Michael <cp.michael@samsung.com>>
Differential Revision: https://phab.enlightenment.org/D7592
so evas cpu used to be the thing then eina cpu came and did the same
and evas cpu optionalyl could lsit on top... just move it all to eina
cpu so one central place does this and evas_cpu is purely a compat
wrapper.
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
Mike Blumenkrantz
Vincent Torri
Carsten Haitzler
Hermet Park
Xavi Artigas
Christopher Michael
Shinwoo Kim
Marcel Hollerbach
Wonki Kim
Derek Foreman
Youngbok Shin
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