evas will use all loaders (brute force) if it can't guess by extension
- this means loaders need to stay quiet about invalid file formats as
this is literally intended to probe if the file is really of that
format when nothng is known about it.
on arm when a is 0 ... per pixel rgb can be > 0 which violates premul
rgb leading to junk rendering. this now is worked around in the png
loader and forces rgb to 0 when a is 0 per pixel.
@fix
i see no good reason to not allow these loaders to run in threads.
they are isolated and i don't see a reason for the libs called to not
be threadsafe.
Summary:
Change-Id: I17c79f89550e9a758a532babd55826b3c7ad2810
To show gif animation smoothly, we keep the current frame even if getting line is failed.
Currently, the frame image will be freed if getting gif line is failed and this makes the frame drop.
Reviewers: Hermet, kimcinoo, raster
Reviewed By: raster
Subscribers: raster, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12277
Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Reviewers: vtorri, jptiz, woohyun, lucas, SPAM-smith78899
Reviewed By: vtorri, SPAM-smith78899
Subscribers: SPAM-smith78899, raster, SPAM-cabanacatalogs, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12228
Summary: and minor fix of some values in avif loader
Test Plan: entice still can read heif
Reviewers: raster
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12257
Summary: libavif can be built without a AV1 decoder. Check this in the image loader
Test Plan: entice
Reviewers: raster
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12252
Summary: that supports images : *.heif, *hiec and *.avif I have disabled *.avif images, there is already a loader.
Reviewers: stefan_schmidt, raster
Subscribers: raster, vtorri, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12135
when a file has no extension to guess by.. evas goes back to trying
every loader until one works. this leads to noise. loaders should not
printf/stder or eina log err anything if the file seems to not be valid.
@fix
Summary:
The strech region has paired information; total and strechable.
Refer to function _strech_region_load retrieving strech region info.
But if 9-patch information line ends with strechable,
png did not push the strechable information.
And it leads to devide by zero.
This patch is adding strechable info to the strech region,
if 9-patch information ends with strechable.
Test Plan:
[Code]
{F4219278}
{F4219280}
[Test]
ECORE_EVAS_ENGINE=opengl_x11 ./evas-image-9patch ./end_with_strech.9.png
Reviewers: Hermet, jsuya, herb, cedric
Reviewed By: Hermet
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12204
Summary: Add AV1 image file loader to Evas
Test Plan: test executable with avif files found in libavif project
Reviewers: raster
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12051
this way we can use that list easily in the modules, and keep the list
for later module building.
Differential Revision: https://phab.enlightenment.org/D11897
libraries are split into deps, external deps, and pub deps.
Evas engines are refactored to use the predefined engine deps.
this is preparation work for efl-one.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11806
Adding it to all missing places so we can control it from the central
meson.build file.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11855
Summary: .9.png is not 9 patch file, but a png file which name is .9
Test Plan: evas_object_image_file_set(image, "./.9.png", NULL);
Reviewers: Hermet, jsuya, herb
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11848
Summary: EAPI must be defined to dllexport when building DLL, and to dllimport when using these DLL. To achieve this, define EFL_BUILD for each library and module, and set DLL_EXPORT unconditionally. Static library are and will be not supported
Test Plan: compilation
Reviewers: zmike, raster, jptiz
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11834
Summary:
There was a mistake caused by "2a0eeba evas: fix png regression issue".
The flag is_for_data was close_file before this commit.
_evas_image_load_file_internal_head_png closes file if it is called only for
header. So the close_file does not mean is_for_data.
This patch is changing is_for_data to is_for_head, and make
_evas_image_load_file_internal_head_png use EINA_FILE_SEQUENTIAL
for data decoding.
Reviewers: Hermet, jsuya, herb, raster
Reviewed By: raster
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11783
Summary:
Accidentally commit "382c580 evas: add support for .9.png file to PNG loader."
adding the 9 patch feature with small code refactoring made use of setjmp
incorrectly.
[Problem]
evas_image_load_file_data_png calls _evas_image_load_file_internal_head_png,
and _evas_image_load_file_internal_head_png calls setjmp and returns without
problem. And png_read_row calls longjmp. This causes jumping into a function
which was exited. Problematic png file will be attached.
[Solution]
Save calling environment i.e. call setjmp, after returning from
_evas_image_load_file_internal_head_png.
Test Plan:
Problematic png file
{F3876983}
And example code.
{F3876986}
Reviewers: Hermet, jsuya, herb
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11782
Summary:
before recent times we had to support static and shared building based
on the options of the user, which forced us to complicate our build with
the evas_goal hack. the evas_goal hack more or less was the idea of
"faking" the evas build in the evas directory, finish all the .eo
generation there, then build the modules and make all the static files
ready. Then build everything in evas_goal.
Now, that we just build everything the same always, we can simply build
it in the evas way (removing the evas_goal hack FINALLY), as the same modules
are build statically and shared.
This also gives us the possibility to build the shared image loaders
*again* the the modules directory, which unbreaks peoples build scripts
who packaged loader files seperatly.
Reviewers: zmike, raster, cedric, stefan_schmidt
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10548
if your platform is picky enough it won't want to leave unresolved
symbols (which wshould be resovled at runtime from the host lib) so we
need to link these modules to evas. the problem is due to the
complicated build of some modules being static and some shared, evas
is declared with evas_goal and this has to be declared after static
modules are declared but since i was declaring static and shared at
the same time from a table this breaks. so i have to move all the
static and shared module stuff into evas_goal into 2 phases. one phase
for the static and one for the shared after evas is delcared so evas
as a target exists to link to.
so the evas modules able to be static or not was a bit pointless as it
could inline all evas modules (or none) not just the most common or
not, but ecore evas modules were still modules, so it really wasn't
being useful.
image loaders ans savers omn the other hand were *ALL* being
statically built in without exception. this was kind of a regression
in the build system in the move to meson. some were static due to
micro optimizations and performance inlining the most common to save a
little extra loading + linking + page fragmentation for loaders you
are likely to need in most cases as well as save the drity pages from
linking in their dependencies (libgif, libtiff, libwebp and all their
dependencies too etc. etc.). this now brings back the ability to
decide which are static and which are shared modules (not exposed to
the user as options for meson - fixed in meson.build files which i
think is good enough given the purpose of this).
fixes ylee's xpm loading issue... it really is just that xpm's didn't
load if you preload/load from a thread... because it wass the only
loader that claimed it couldnt be threaded... which it can be.
@fix
Accidentally commit "382c580 evas: add support for .9.png file to PNG loader."
adding the 9 patch feature with small code refactoring missed a line calling
eina_file_map_all taking EINA_FILE_SEQUENTIAL for data decoding.
You can see the previous change adding the line from the following commit.
e60baa0 evas: change mapping policy to be less agressive into loading file
in memory.
This is a response to the request of @cedric on D9580
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9614
Summary:
integrate mman.h to make Evil private to the EFL, as mman.h does not exist on Windows. After a discussion with raster, i include sys/mman.h only on non Windows platform.
One issue, though, is that src/modules/emotion/generic/Emotion_Generic_Plugin.h has inlined functions using mmap()
Test Plan: compilation on Windows
Reviewers: cedric, raster, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9542
Summary:
The evas_image_load_file_data_png had called png_set_tRNS_to_alpha
from following commit.
6988a38 evas: fix png loader to actually produce lower resolution
content when asked.
You could refer to following information regarding png_set_tRNS_to_alpha
which is available on page http://www.libpng.org/pub/png/libpng-manual.txt
The following code transforms grayscale images of less than 8 to 8 bits,
changes paletted images to RGB, and adds a full alpha channel if there is
transparency information in a tRNS chunk. This is most useful on
grayscale images with bit depths of 2 or 4 or if there is a multiple-image
viewing application that wishes to treat all images in the same way.
if (color_type == PNG_COLOR_TYPE_PALETTE)
png_set_palette_to_rgb(png_ptr);
if (png_get_valid(png_ptr, info_ptr,
PNG_INFO_tRNS)) png_set_tRNS_to_alpha(png_ptr);
if (color_type == PNG_COLOR_TYPE_GRAY &&
bit_depth < 8) png_set_expand_gray_1_2_4_to_8(png_ptr)
Accidentally commit "382c580 evas: add support for .9.png file to PNG loader."
adding a new feature with small code refactoring missed the line calling
png_set_tRNS_to_alpha.
So we got a rendering issue. It made around 75% size white rectangle
using a grayscale and transparent image. I'd like to attach the image
which has following type information for test purpose.
$ identify -verbose ./grayscale_transparent.png | grep type -i
Mime type: image/png
Type: Bilevel
png:IHDR.color-type-orig: 0
png:IHDR.color_type: 0 (Grayscale)
Test Plan:
This is the sample image file grayscale_transparent.png
{F3748665}
Reviewers: cedric, Hermet, jsuya
Reviewed By: Hermet
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9580
tracking some seemingly not so good asan hits on the eina file where
we're accessing an eina file already closed... so be extra paranoid
about it and set things to null after free/close...
Carsten Haitzler
Vincent Torri
Taehyub Kim
Felipe Magno de Almeida
Vincent Torri
thierry1970
Shinwoo Kim
Elyes HAOUAS
Marcel Hollerbach
Stefan Schmidt
Hermet Park
Boris Faure