this is a bit ugly, but in the case where skip_head is used it's important
to propagate the resulting Eina_File back up to the image object's data
for use in other api functions
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11422
Summary:
When a newly created Image_Entry works for instead of an old one,
we need to drop it. And we did dorp it.
The line calling ref and drop was added by following commit.
d550190 evas image cache - add lots more locking to try stamp out
any thread bug
But it is missed by following commit.
9f99ab1 evas cache: clear up caching locking and reference count.
Reviewers: Hermet, raster, jsuya, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10333
in 1 situation at least we delete the eina file (close it) but keep
the ptr around (during destruction) which could cause issues with
callbaks and events on del and so on.... which may lead to multiple
closes where only one should happen ... which would explain my invalid
eina file ref problems i'm seeing. i carefully matched eina file
handle stores/opens/dups to closes in edje/evas and they seemed to all
match up so this audit with comments and fixes seems to have plugged
that now.
@fix
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...
As cache2 knows cached image could be not matched even though
hash key is not different.
Please refer to the following comment of evas_cache2_image_open.
/* image we found doesn't match what's on disk (stat info wise)
* so dirty the active cache entry so we never find it again. this
* also implicitly guarantees that we only have 1 active copy
* of an image at a given key. we wither find it and keep re-reffing
* it or we dirty it and get it out */
The hash key is created base on the image file address.
If the image file address to find does not equal cached image file address
then it means that the cached image is no longer valid.
This case could happen with the following step.
(1) Call evas_object_image_memfile_set with content data A
(2) Call evas_object_image_memfile_set with content data B
(3) Add timer with short time (ex: 0.01 sec)
(4) Delete A image, and add A image in timer callback
(5) Delete B image, and add B image in timer callback
Sometimes you could see image of A from the B image, because newly created
image at step 5 has same address of setp 1.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D6870
Summary:
On reviewing, found out some logical problems in evas cache.
ref-drop pair doesn't make sense, proper locking for cache image neither.
Reviewers: raster, #reviewers
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7129
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:
The 'cache' pointer is checked against null but then
dereferenced anyway. It needs to add null checking conditions.
Test Plan: N/A
Reviewers: raster, cedric, Hermet, zmike
Reviewed By: Hermet
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7084
Summary:
Current preloading is too buggy since it's on thread-based.
This is a fundamental improvement to fix a bug.
The critical issue here is,
When preloading img object suddenly cancel its preloading,
the object possibly cannot render image next then because
renderer doesn't have any idea when async cancelling is
finished. Renderer just tries to render regardless of
image loading status, and this could occur no-texture(in gl case)
image object.
So, here improvement is, adding a notification for async cancelled
so that putting img objects to redraw images properly after their preloading is
cancelled.
The best scenario to reproduce this bug is this one.
Evas_Object *img2 = evas_object_image_filled_add(evas);
evas_object_image_file_set(img2, "test.jpg", NULL);
evas_object_image_preload(img2, EINA_FALSE);
evas_object_resize(img2, 200, 200);
evas_object_show(img2);
Evas_Object *img = evas_object_image_filled_add(evas);
evas_object_image_file_set(img, "test.jpg", NULL);
evas_object_image_preload(img, EINA_FALSE);
evas_object_move(img, 200, 200);
evas_object_resize(img, 200, 200);
evas_object_show(img);
evas_object_image_preload(img2, EINA_TRUE);
If you run this on gl backend, occasionally happens rendering fail.
Yet there other bugs on preloading feature....
@fix
Reviewers: #committers, raster
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6919
Summary:
Adding cache targets in other modules are inproper.
This can't be managed by cache module inside.
One representive scenario is,
when preload cancel is triggered, preload canceling sequence
can't be performed properly because cache targets implicitly were
increased by backend modules.
And then, Cache itself couldn't get notified it.
see this condition.
if ((!ie->targets) && (ie->preload) && (!ie->flags.pending))
in _evas_cache_image_entry_preload_remove()
Consequently, I move preloaded callbacks to sync with adding cache targets,
not to add by backed engines themselves.
This will bring Cache to manage cache targets properly.
Reviewers: #committers, raster
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6912
Summary:
That redundant code just made code complex.
This is one of intermediate patches for preload
Reviewers: raster, #committers
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6907
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
ok. i can't find the root cause because all i have is a backtrace from
ApBBB and he says he can't reproduce it and i know im->cache is
null... if i could reproduce ... i'd be hunting the root cause. but
the best i can do is check for null im->cvache ptrs and be safe.
crashes are bad. especially for end users.
These timestamp functions are not currently being called, perhaps they
were intended for something later?, but for now just #if 0 them out as
they are not used
Signed-off-by: Chris Michael <cp.michael@samsung.com>
just match the ref with the drop anddon't also manually free the image
as this leads to accessing of freed memory which is not a good thing.
this should fix T5374
@fix
this definitely fixes T5223 because it adds an engine lock around the
code segemtnt that does compare time stamps... and hopefulyl a few
more things too.
@fix
cache flish and async end ended up dropping some cacneled images that
were then accessed further in the cancel func for the thread. this
fixes that
@fix
so if you queue a preload while a cancel is still pending the new
preload never happens. this fixes that. now it does but checking for
leftover tasks in the cancel cb and rescheduling a preload thread.
@fix
to date if you use async preload we still load the header
synchronously and this can be horrible especially with generic
loaders. there is no way to farm this off to the preload thread. now
there is. youhave to set it as a skip head load option before doing a
file_set AND you need to issue a preload ... but now it's possible.
@feature
this doenst change functionality but just cleans up the file
whitespacing and formatting and removed commented out junk, 80 column
wrapping/overflow etc.
SEGV would happen if the cache was NULL, as the error pointer
was also NULL in some cases (root cause for cache == NULL not
quite known, happens in elm_suite with CK_FORK=no).
Note: simply adding evas_common_init() to evas_init() leads to
a whole new set of issues with CK_FORK=no elm_suite - not good.
Carsten Haitzler
Mike Blumenkrantz
Shinwoo Kim
Vincent Torri
Hermet Park
Marcel Hollerbach
Youngbok Shin
Chris Michael
Cedric BAIL
Mike Blumenkrantz
Jean-Philippe Andre