Evas uses BGRA data while rg_etc1 uses RGBA data, so there
were incompatibilities between the two.
Now, rg_etc1 will take BGRA data as input and output.
Since the introduction of new colorspaces for GL_X11
(GRY8, AGRY88 and ETC1), stride_get() would return
an invalid value and data_get() would just abort().
Add proper support for these functions.
ETC1 data will NOT be returned from data_get() and
stride_get() will return 0. This is to avoid people from
messing up badly with encoded color spaces.
So I must have been a bit tired last Friday when "fixing" some
code producing artifacts, as I was just basically disabling part
of the code without realizing it :)
Let's just disable it then.
@fix
Summary:
In emotion_engine_instance_new(), if given module name is wrong or if loding is failed, fallback module loading should be triggered.a (previously, it check just whether name is NULL or not)
In case of T1025, "vlc" was given name. Therefore, fallback was not triggered.
Fixes T1025
Test Plan: enlightenment -> efm -> mouse over multimedia files -> check whether preview is shown properly or not
Reviewers: raster, cedric
CC: seoz, cedric, zmike
Maniphest Tasks: T1025
Differential Revision: https://phab.enlightenment.org/D773
Quality should not default to 100 unless specified in the
command line. In particular, we don't want to save ETC1 at
high quality by default since it can take hours (literally).
Add some comments as I'm reading and understanding the code.
Fix some rare artifacts happening mostly with medium quality
encoding, where a few pixels (2x2, 2x4 or 4x2) will have a
horrible contrast with their surroundings (eg. pink over black).
Add a new flag in EDC files to specify ETC1 compression
should be enabled. It follows the same rules as the
current LOSSY flag for JPEG compression.
@feature
The ETC1 encoder is expected to write all 8 bytes of the
output data. But in case of a solid color block, it was writing
only 1 of the first 3 bytes (R, G, B). So lots of solid blocks
were containing invalid data (for instance: R + dR < 0 or > 255).
There were a few critical issues:
- Invalid pointer arithmetics on the input data (char vs. int)
- Invalid logic in the pixel duplication code
All of these due to bad copy and paste :(
Also, use LZ4HC instead of LZ4 when compression is enabled.
ETC1 encoding is so damn slow you won't see the difference between
LZ4 and LZ4HC compression times.
Summary:
Changed uses of EINA_MAIN_LOOP_CHECK_RETURN for EINA_MAIN_LOOP_CHECK_RETURN_VAL
for functions that doesn't have void return types.
These only error out when compiling with --with-profile=debug
@fixed
Reviewers: raster, cedric, smohanty
CC: cedric
Differential Revision: https://phab.enlightenment.org/D765
Summary:
Due to unnecessary magic checking, there was freezing in /proc in efm.
Proc file's st_size is zero, but, it's readable. therfore, it takes unnecessary time in magic checking. And, there is no need to check magic in case of 0 sized regular files as well.
Therefore, skip magic check in case of st_size is zero.
Fixes T1173
Test Plan: enlightenment -> file browser (efm) -> get int /proc --> check whether efm freezes or not
Reviewers: raster, cedric, zmike
CC: seoz, cedric
Maniphest Tasks: T1173
Differential Revision: https://phab.enlightenment.org/D764
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
The _ecore_wl_cb_handle_data callback only has the flag for ECORE_FD_READ
set while the callback funtion also monitors and acts on writes. I wonder
if and how that worked before.
Since the introduction of color spaces other than RGBA8888 in
the GL engines, there was an issue with border images scaled in
GL. The left and right edges were simply not properly copied.
This would then show artifacts when scaling very thin images
(typically 2px wide).
The default quality is 80 and high quality is horribly slow,
so default to medium quality instead (it's already very slow).
If you really want to shoot yourself in the foot and use high
quality, just set quality > 95 and go make some coffee.
Also, disable dithering, it creates horrible artifacts on real
life pictures (gradients and flat surfaces especially).
the comments say it all. this stops adding massive full window updates
when clippers lose all children (and are visible) or gain a first
child while visible as all code hides these clip rects (or shows them)
in these cases and other usages just make no sense.
due to recent changes a lot of objects are now NULL (correctly) and eo
complains on access of them. it's simply too noisy adding too many
if's all through code, so let's just make eo be sensible here.
LZ4HC has a higher compression ratio than LZ4 but basically the
same decompression speed.
The performance cost during encoding is actually still pretty low
considering how expensive ETC1 compression can be (even at medium
quality).