This is a regression in listed projects
Fri, Oct 4
Mon, Sep 30
Fri, Sep 27
For the record: I have a svg icon theme.
I think this is fixed by the svg fix you provided. I cannot reproduce this anymore.
Thu, Sep 26
Wed, Sep 25
Possible way to track it down is to run enlightenment under Xephyr by passing -massif to enlightenment_start and try to reproduce it that way. It should give deeper meaningful trace and associate it with timing information that could lead to an understanding of what is going on. It might be linked to specific engine configuration like texture mapping stuff.
I have been running expedite under massif and only found a leak in the VG part. Nothing that would explain enlightenment leak.
I expected this to be from the cursor idle animations, but I created a test app to simulate it and after an hour or so there were no leaks.
Tue, Sep 24
Sep 18 2019
Sep 13 2019
Resolut by D9900
Sep 11 2019
Sep 10 2019
Sep 9 2019
I haven't touched it, so no idea what it may be. Also, EDI uses textgrid I think, not textblock, so it's nothing I even ever touched before.
This sounds like a text regression.
Sep 6 2019
Sep 5 2019
Sep 4 2019
Aug 27 2019
Aug 12 2019
cool. i saw those :) let's call this done for now.
Aug 11 2019
Regarding other findings
Right now am concentrating on reducing number of memory allocation and string parsing during startup time as well as memory consumption ( unnecessary ) . Will tag you when I raise a patch or bug against it.
I saw your patch already landed in master. Awesome :)
yeah. actually found bug #2 in that patch. i still have one of my unlocked funcs still lock. forgot to remove them... now down to .... 28 locks to start elm test. so... update. locally with an updated patch... 615604 -> 28 lock+unlock cycles. i think... that will be good enough eh? :) even if a read lock is 3x as expensive... we do it 0.004% as much as before, and still get the write contention improvements. :) i call this a win.
cool. so i guessed what you wanted. btw that patch has a small bug in it. find it :) (i already have and fixed it locally). it won't affect running things and testing performance though.
Aug 10 2019
btw... that should actually be faster than the original spinlock before rwlock as it's even less lock+unlocks. as it's a rwlock multiple readers will not block each-other unlike spinlocks too. only a writer will end up blocking others and that path i have left as-is.
so do you mean something like: P319
nah - just a performance thing and it's not a huge one... it's only in some code paths. so not showstopper
Jul 25 2019
Jul 13 2019
Jul 11 2019
False alarm, dunno what it was.
Jul 9 2019
Yes, that fixed it, thanks.