i was runing perf top and noticed that evas_image_load_file_data_eet(0
was being called. in fact - it was #1 on the list of functions being
called. why? it didn't make sense. i found out. just a blinking cursor
in terminology was causing the background to be unloaded and
re-loaded. the new "actually unload" changes for 1.15 made this happen
and thus we kept sucking in new data all the time even if the
scalecache already had the data - and that was the problem.
so now calcecache prepare tells you if you don't have cached data and
if you likely then have to ensure the data is loaded. this cuts down
quite a bit of work.
while i'm at it... we definitely need to clean house on the internals
of evas. a decade+ of features, mess, optimizations needs to be fixed.
i mean really house-cleaned. rewritten clenl;y re-using existing code
where appropriate.
For unset color_class for part used edje_edit_state_color_class_set and NULL
value for color_class, it's a string, is valid. In this case function must
return EINA_TRUE.
@fix
It's now generalized to work properly with legacy functions
as well as correctly append suffixes. Thus, it can be easily
used with the documentation generator and in other places.
@feature
this was broken in 5cb6cdbc5e such that
when multiple sources produce mouse events using the same device,
these events are marshalled as though they were from the same canvas.
the result is that eventing is wrong on at least one of the canvases,
and spurious mouse-up events are triggered before every mouse down
fix T2509
i think this has been disabled for a while. image unloading is broken
- esp with gl enigne as due to async move it was effectively disabled.
this re-enables it. unloading is deferred with a managed list of things
needing unloading and then when any async sw renders are not busy any
more - do the unload then in the mainloop of all pending/flagged
images to unload
@fix
Since the move to eo, ecore_con_local hangs on Windows, hence edje_cc can
not compile edc files (e.g.).
Problem was a loop that was used to finish some threads which is now endless.
For now, comment out that loop
@fix
The correct way of disposing of an object in a failed finalisation is to
return NULL, not to delete it.
Also, since the destructor is already called when the object is deleted
anyway, there's no point in having cleanup code in the finalizer too.
@fix
Sorry for last minute new API, but this one is necessary to implement
proper verification of references in docs, which I would like to have
in 1.15. It allows you to retrieve any kind of declaration by full
namespace, so that you can check for an existence of an Eolian decl,
rather than checking every type individually.
@feature
efreet will just match any desktop file (at random basically -
whatever is first in the list), thjat has the base command looked at.
if you have various desktip files with the same command, like:
mycommand
mycommand %U
mycommand -a -b -c /path/to/file
/usr/bin/mycommand
etc. - which one does it match? it'll pick the first and the list
ordering is arbitrary, so this is pretty bad. this strips off the base
command at the start (full path or whatever) and then uses the command
with the shortest argument length. this means the generic command is
found first if we look for "mycommand" in the above list, whihc ends
up the best... ESPECIALLY for steam which does just this.
Summary: This is an algorithm which calcuates a convex hull of some mesh, in fact it returns vertex, index, normal and color datas, though the new mesh could be build just as for AABB
Reviewers: raster, Hermet, cedric
Subscribers: cedric, artem.popov
Differential Revision: https://phab.enlightenment.org/D2585
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Carsten Haitzler
Daniel Kolesa
Srivardhan Hebbar
Tom Hacohen
Hosang Kim
Daniel Juyung Seo
Mike Blumenkrantz
Chris Michael
Vincent Torri
Vyacheslav Reutskiy
Jean-Philippe Andre
WooHyun Jung
perepelits.m
Vivek Ellur