Summary:
Before "open_done" callback, play unset is ineffective.
is it intentional logic?
if we set play and unset play again before "open_done" callback, the video will be played.
@fix
Reviewers: raster, cedric
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D786
partly revert adcc323291 as the default
ellipsis value was 0 as per the document, and must stay, as changing
this breaks edc descirptions as now text is no longer ellipsised by
default. this ACTUALLY broke titlebars on the default theme - just
have a title that is too long and see how it no longer goes:
This is a title he...
it instead covers the screen for as long as the title is.
if you want -1 for ellipsis... then set it. :)
what a huge, colossal cock-up of a clusterfuck. it's a good thing nobody ever uses ellipses or edje. otherwise we'd probably get complaints about this kind of thing.
this should always be applied, not just when min_x isn't set; failure to do so causes erroneous ellipsizing in some cases where it should be explicitly prohibited
@fix
define scope keywords 'protected' and 'public'
disallow scope keywords as property or method name
use move_ts action to move token start after scope modifier if found
use end_property_scope and end_method_scope actions to handle it
Since rg_etc1 now outputs proper BGRA data, the shaders should not
swizzle the colors around. Stick to the normal fragment shaders.
Note: This is not tested.
this fixes and eo2 problem where when callstack grows (or shrinks)
and realloc nas to relocate memory, the frame ptrs like fptr become
invalid and all sorts of hell ensues.
this uses mmap so blowing the stack will segv, not scribble over
memory, also its separated from malloc heap, and now big enough to not
need to size ... ever (1024 entries).
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.