Summary:
During shutdown we used to call engine_image_free() which was causing some deadlock.
as we have evas_cache which takes care of freeing all the images we just have to
delete the generic cache without freeing the image during shutdown.
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11915
The former is a POSIX name, the latter is non-standard. I don't
know why the latter was used, considering glibc literally has
just #define LC_ALL __LC_ALL, but change it and unbreak build
on musl and other systems.
regions sometimes produce box sets like:
// +---+
// | |
// +---+ +-------+
// | | | |
// +---+ +-------+---------+
// | |
// | |
// +-----------------+
so the upper-left 2 boxes can be merged into 1 and they have the same
x coords and are flush-aligned one above the other. that is what
this does - find these and merge them to have fewer rects
@fix
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:
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
Since we moved to floating calculation for msaa, this comparsion
is not working for direct image drawing though it's doable.
To resolve this, we can compare floatings regardless of msaa enable.
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
we were losing cached chaders and overwriting the cache all the time
when apps finished compiling new shaders and at other points... when
they should have already had a populated shader cache that was all
fine and happy. this fixes that so once the cache is fully populated
it wont write anymore and it wont lose existing shaders in the cache
@fix
Summary:
since the existance of seleciton manager, the converter callbacks from
ecore_x are expecting custom struct pointers. However, enlightenment
never updated to use the elm dnd API for client side usages. Which
results in the fact that sometimes, when a client sents Notify, and
e_dnd is active, that this converter is executed with the wrong data.
With this commit the data passed in is ensured to have the correct magic
number. The proper solution for this would either be registering the
correct converters in enlightenment, or update to elm_drag. However,
since the continues cried river over the last 5 days has raised enough
hydro power to add these changes. This leaves us with just one question:
How was it possible to generate so many messages about a problem that
can be solved in a fraction of charaters that have been written?
fixes <a-issue-that-was-never-created>
Depends on D11700
Reviewers: zmike, stefan_schmidt, raster
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11701
Summary:
this is needed in order to tell the API user that this is not going to
be completed.
Depends on D11699
Reviewers: zmike, raster, stefan_schmidt
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11700
Summary:
ecore_x_dnd_send_status can be used to indicate if a item can be dropped
on a client or not. However, we should only indicate that this can be
dropped, if there is a object we signaled that a drop is in.
Long story short: there is no assertion that after indicating that
things can be dropped, that a notify for the data is sent. A drag
implementation should always listen to a mouse up event, and abort the
drag if no further operations are sent.
Depends on D11698
Reviewers: zmike, stefan_schmidt, raster
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11699
Summary:
this is needed in order to return the data the same way the legacy impl
did. This however has the annoying sideeffect that ecore_evas_x now
depends on efreet, and we had to change the build order.
Depends on D11696
Reviewers: zmike, stefan_schmidt, raster
Reviewed By: zmike
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11697
Summary:
Static analysis tool reports passing a null pointer 'im->gc' to
_evas_gl_image_cache_add which directly dereferences it, so lets
be sure that 'im->gc' is valid before passing it to cache_add
Reviewers: Hermet, jsuya, herb, zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11676
this will now result in the promise beeing rejected.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11653
this is just causing errors and nothing usefull, upower is not available
on macos.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11652
A long story in a few words: sometimes on macos modules will be compiled
into .dylib, sometimes, into .so suffix. We did not set the suffix
everywhere in our meson build instructions, hence our suffixes have been
differently, which resulted in random load fails on different maschines.
With this commit, we ensure that we suffix all modules the same way.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11650
memory is duplicated in eina_content_new.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11641
the structure "!strcmp(X, "foo", strlen("foo"))" is equal to
"eina_has_prefix(X, "foo")", and the later is nicer to read, hence this
replaces it.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11620
this pointer needs to be freed if it's being copied
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11604
Coverity reports that 'fd' here is negative, and close() cannot accept
a negative parameter, so add a check to make sure 'fd' is not negative
before passing to close function.
Fixes CID1420318
write() cannot be passed a negative value. If
ecore_main_fd_handler_fd_get returns -1, then this is an issue. Check
for valid fd being returned from fd_handler_fd_get and if it is
negative, then cleanup and get out.
Fixes CID1420318
If we are going to be exiting this function without setting up the
ecore_main_fd_handler (and thus passing forign_slice), then we should
free forign_slice as it was previously calloc'd above.
Fixes CID1420322
I thought that i explicitly tested this. However, it seems i was wrong,
this way now this is handled correctly, and the image is stored and
coverted to a path.
With this you can now copy images from chromium and firefox to elm apps.
The change in elm_entry reverts parts of the rewrite of the elm
handling, as initially every path came *without* "file://" in front, so
we have to maintain that.
fixes T8625
enlightenment does not use the elm dnd operation implementations.
Therefore we have to ensure that we only handle these operations here,
when ecore_evas dnd API is used.
gc width/height indicates the main output size,
if the target surface(fbo) is larger than this, rect won't be drawn.
We should clip this with current context size.
@fix
Some methods were missing the "Drag" or "Selection" namespaces or the _Cb suffix.
Depends on D11219
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11426
Including Eina.Content
And a typo/bugfix in ecore_evas_x.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11204
Stefan Schmidt
Subhransu Mohanty
Hermet Park
Daniel Kolesa
Carsten Haitzler
Shinwoo Kim
Christopher Michael
Ali Alzyod
Marcel Hollerbach
Mike Blumenkrantz
Vincent Torri
Xavi Artigas