The setup script copied ALL media files, but only the C# tutorials and guides.
A lot of space can be saved in the generated _site folder if only the media
files relevant to C# are copied.
Summary: it crashes when calling elm_interface_scrollable_loop_get() function with NULL parameters.
Test Plan: call elm_interface_scrollable_loop_get() function with NULL parameters.
Reviewers: Hermet, woohyun, kimcinoo, zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9082
Summary:
to correctly (and quickly) calculate part geometry when setting a part relative
to another part, align must be set on the axis that is relative to another part.
also since the height on this part should not be changing, set fixed on the
vertical axis to optimize geometry calcs
@fix
Depends on D9009
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9010
i saw a segv in e/efm .. an eio call was called after it had been
canceled. this should never happen. ever. so ensure it does not once
an eio file has been canceled.
@fix
so we USED to... if buffer age changed between frames, force a full
redraw and add that to the pipeline... somehow someone removed that.
this brings that back as it's really needed to deal with updating
correctly.
@fix
so it turns out a fix to an optimization i did was ALSO a fix to an
existing bug that just didn't turn up as much until i added an
optimization. this is that fix backported manually
@fix
i found some more cases where the hash may change, so del and add from
the hash when this happens...
and... i found a nasty. _edje_signal_match_key_cmp compared pointers
like:
int return = ptr_a - ptr_b;
what happens if .... ptr_a and ptr_b are more than 2^31 (2gb) apart?
overflow (or underflow) and we return the wrong thing. i suspect this
is part of the problem and why my has remove/adds have not been
working because ... i suspect that maybe the hash dels have not been
finding things. i can't be sure right now, but it is an obvious
problem that i fixed by just doing if's and returning -1 or 1. also i
found a double-add or overwrite int he hash - when we shuffled with
_edje_signal_callback_move_last the matches CAN match exactly
something already in the hash thus adding it in will conflict with
what is already there as keys match. handle this cvase now and i have
seen segv's go away for now.
@fix
Summary:
alloca force the memory to be accessible for the entire duration of the
scope of the function it is called from. This will garantee that the
memory pointer are not recycled under our feet before we check them.
T8020
Reviewers: zmike
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8020
Differential Revision: https://phab.enlightenment.org/D9127
so i think there was also another bug as i saw this again now. this
should hopefully plug the signal/mtach memory bugs now by removing
and adding back to hash as the hash key relies on the memory addresses
of signal/src in the matches array which change on realloc. a bit
brute-forceey but... better than crashes.
@fix
also a general cleanup of the code to make it easier to follow/read as
this seems to have problems but i cant reproduce them enough to find
them. i noted a realloc would have invalidated pre-stored pattern
ptrs that would cause segv's for sure. also code paths where reallocs may
fail and not handling those cases at all etc.
@fix
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
so if you use sw and gl enignes in a process and have color font
glyphs.. *BOOM* because the color glyph code used ext dat that was
intended for engines to extend with a gotcha of "only 1 engine can
extend this"... commented already.
so this unfortunately adds an extra ptr per glyph to store color data
explicitly. but now it both renders right and doesn't crash. we still
have a limit of 1 engine alone can extend glyphs with ext_dat though.
@fix
in the case pipes fail to create we'll close the wrong ones... this
fixes that. it also happens because i didn't use names consistently.
now it does so it's easier to keep right.
thanks coverity.
fix CID 1396994
also.. note the badness of the code design mixing a global singleton
with a "per struct" set of data like fd handlers for the same devices
initted only once but... anyway. it's messy.
so even if shm was an allowed mode/flag, we never fell back to shm if
dmabufs were not possible (/dev/dri/renderD128 didn't exist or wansn't
open-able). that's decidedly a bad thing to do.
@fix
i saw a segv on freeing em->msg as it was a junk ptr... i dont know
for sure it msg was properly initted but as em is recycled from trash
be sure and zero it when digging out of trash because em->msg was not
a valid ptr (and i wasnt using valgrind at the time to know for sure
and cant find this with valgrind now).
@fix
during cursor free a move cb seems to add another job again after it
wss already deleted during the free process, so just clear the job
really late instead. valgrind found this one
@fix
so i've been wondering what is going on for a few days... and i've
figured it out finally... my mouse seems ot like to generate 1000
events per second. not your usual 100 or 200. it only happened on this
one machine so i was wondering what on earth was up. this machine was
different in other ways like an arm cpu, differing gpu (rx550),
different distro and so on. this is creating a storm of motion events..
and this is causing all sorts of overhead in just trying to deal with
them all like generate more internal events, emit signals for every
one of them and so on. there is no attempt to play catch-up or
anything - just build up a bigger and bigger queue of them to deal
with. this is NOT GOOD. this restores our old commented out event
skipper that got commented out during some xcb work actually -
not on its own. it was a huge xcb patch that commented it out.
this restores it and makes it a little cleaner with a bool and now the
perf issues i was seeing are gone. this is such a major performance
fix that this deserves a backport.
@fix @optimize
i missed 1 rare case where we start in the middle of the list and have
to walk to the end. testing didnt show it up. fix. this fixes up that
case in b5ed76ba9f
to walk inreverse we need to jump to last first then walk backwards...
what we were doing is calling eina_inlist_last() which is defined to
walk rather than that using list->last ... this totally got rid of
_evas_event_object_list_raw_in_get() from my perf list ... and i was
wondering how it got there to start with.
this is such an obvious optimization...
more optimizations for edje messages to avoid excess alloc and frees
if we have some trash around... since messages already have list
nodes, re-use the main list node for storing trash and not eina trash
as this avoids extra allocs for trash nodes.
so to process a single obj we added a lot of mesgs to the message
queueue only then to wak most and SKIP most msgs again and again -
when this adds up to 1000's of messages and 10k+ then literally moving
a window in e hangs for multiple seconds and we walk such lists in On2
like complexity. this gets it down to O(1) along with some other minor
optimizations of not adding to tmp list only then to add them to the
nex queue/list.
there is more i can optimize here as well now we track messages for an
edje in th edje. that's next.
Xavi Artigas
Christopher Michael
Jongmin Lee
Mike Blumenkrantz
Carsten Haitzler
Cedric BAIL
Alastair Poole