basic canvas operations and rendering mechanisms
Jul 14 2020
May 25 2020
Hi, thank you for coming back to this.
As a general note:
May 20 2020
HI :) I did a little check to solve this.
I understand why you should replace void * with array <> or iterator <>....
However, efl_gfx_path uses the data transmitted as parameters from user side and does not manage path memory separately.
If this is changed, the user who has used the existing API or the legacy API must create and pass the array type data. or legacy path apis manage to array memory.
I think, we are not ready for that yet. The path is used in many places.
Apr 20 2020
will have a look.
Oct 31 2019
Oct 30 2019
Oct 29 2019
Oct 17 2019
Oct 14 2019
Oct 10 2019
Let's close it :)
Oct 9 2019
I played just a bit with the gifs like it happened to me before and I don't see the flickering anymore... bug fixed? :)
Oct 1 2019
This is working now. Fixed by commit https://git.enlightenment.org/core/efl.git/commit/?id=13ecc4898c23aa58421a847efbe5392d2b18cef8
Sep 27 2019
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.
Sep 25 2019
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.
Sep 24 2019
Sep 23 2019
@stefan_schmidt I tested this with everything updated this morning. It works just fine when using software rendering, however when I try to test with gl rendering, nothing works .... not even elementary_test :( so I am unsure what to do here.
Sep 19 2019
@stefan_schmidt Yes, I am actively looking into this. Apologies for missing your message on the 13th, but for some odd reason, I did not get a Phab email about it :(
Sep 18 2019
Sep 13 2019
@devilhorns as our remaining wayland expert could you please check on this? Reproduce this with latest efl and weston and see if you can find a fix?
Sep 3 2019
Aug 8 2019
Jul 30 2019
Jul 18 2019
I have no further complains regarding documentation. Was the code ever reviewed? @Hermet ?
rename to has_fixed_size
rename to has_fixed_size
Jul 12 2019
The requirement is that it does not change size, this is true, but the fully optimized render path requires that it does not change size or move. For some cases moving will not affect the speed, but it requires some deep knowledge of render internals to be able to make that distinction.
Jul 11 2019
Jun 3 2019
Jun 2 2019
May 30 2019
Indeed, I missed that.