so i was just about to add buffer age debugging evlogs to everywhere
doing buffer age and i found... drm gl and wayland gl engines DONT
HANDLE age change like gl_x11! they dont reset to a "full render" for
that frame. well well. this explains bugs i am seeing for sure. very
very bag! i thought this was handled properly. this does lend some
credence to my thoughts about somehow having a single universal buffer
swapping/update calculating and "applying" api inside efl somewhere...
anyway - this fixes this issue for these 2 engines which is a real
necessary fix to be correct.
@fix
Animations are not supported by Exactness. The test screenshots were not
giving any kind of information as they were taken only when the front
was displayed on the screen.
With this change, animations set on the back of the flip can be replaced by
a background, meaning that flip switches can be checked.
so i have been doing some profiling on my rpi3 ... and it seems
memcmp() is like the number one top used function - especially running
e in wayland compositor mode. it uses accoring to perf top about 9-15%
of samples (samples are not adding up to 100%). no - i cant seem to
get a call graph because all that happens is the whole kernel locks up
solid if i try, so i can only get the leaf node call stats. what
function was currently active at the sample time. memcmp is the
biggest by far. 2-3 times anything else.
13.47% libarmmem.so [.] memcmp
6.43% libevas.so.1.18.99 [.] _evas_render_phase1_object_pro
4.74% libevas.so.1.18.99 [.] evas_render_updates_internal.c
2.84% libeo.so.1.18.99 [.] _eo_obj_pointer_get
2.49% libevas.so.1.18.99 [.] evas_render_updates_internal_l
2.03% libpthread-2.24.so [.] pthread_getspecific
1.61% libeo.so.1.18.99 [.] efl_data_scope_get
1.60% libevas.so.1.18.99 [.] _evas_event_object_list_raw_in
1.54% libevas.so.1.18.99 [.] evas_object_smart_changed_get
1.32% libgcc_s.so.1 [.] __udivsi3
1.21% libevas.so.1.18.99 [.] evas_object_is_active
1.14% libc-2.24.so [.] malloc
0.96% libevas.so.1.18.99 [.] evas_render_mapped
0.85% libeo.so.1.18.99 [.] efl_isa
yeah. it's perf. it's sampling so not 100% accurate, but close to
"good enough" for the bigger stuff. so interestingly memcmp() is
actually in a special library/module (libarmmem.so) and is a REAL
function call. so doing memcmp's for small bits of memory ESPECIALLY
when we know their size in advance is not great. i am not sure our own
use of memcmp() is the actual culprit because even with this patch
memcmp still is right up there. we use it for stringshare which is
harder to remove as stringshare has variable sized memory blobs to
compare.
but the point remains - memcmp() is an ACTUAL function call. even on
x86 (i checked the assembly). and replacing it with a static inline
custom comparer is better. in fact i did that and benchmarked it as a
sample case for eina_tiler which has 4 ints (16 bytes) to compare
every time. i also compiled to assembly on x86 to inspect and make sure
things made sense.
the text color compare was just comparing 4 bytes as a color (an int
worth) which was silly to use memcmp on as it could just cast to an
int and do a == b. the map was a little more evil as it was 2 ptrs
plus 2 bitfields, but the way bitfields work means i can assume the
last byte is both bitfields combined. i can be a little more evil for
the rect tests as 4 ints compared is the same as comparing 2 long
longs (64bit types). yes. don't get pedantic. all platforms efl works
on work this way and this is a base assumption in efl and it's true
everywhere worth talking about.
yes - i tried __int128 too. it was not faster on x86 anyway and can't
compile on armv7. in my speed tests on x86-64, comparing 2 rects by
casting to a struct of 2 long long's and comparing just those is 70%
faster than comapring 4 ints. and the 2 long longs is 360% faster than
a memcmp. on arm (my rpi3) the long long is 12% faster than the 4 ints,
and it is 226% faster than a memcmp().
it'd be best if we didnt even have to compare at all, but with these
algorithms we do, so doing it faster is better.
we probably should nuke all the memcmp's we have that are not of large
bits of memory or variable sized bits of memory.
i set breakpoints for memcmp and found at least a chunk in efl. but
also it seems the vc4 driver was also doing it too. i have no idea how
much memory it was doing this to and it may ultimately be the biggest
culprit here, BUT we may as well reduce our overhead since i've found
this anyway. less "false positives" when hunting problems.
why am i doing this? i'm setting framerate hiccups. eg like we drop 3,
5 or 10 frames, then drop another bunch, then go back to smooth, then
this hiccup again. finding out WHAT is causing that hiccup is hard. i
can only SEE the hiccups on my rpi3 - not on x86. i am not so sure
it's cpufreq bouncing about as i've locked cpu to 600mhz and it still
happens. it's something else. maybe something we are polling? maybe
it's something in our drm/kms backend? maybe its in the vc4 drivers or
kernel parts? i have no idea. trying to hunt this is hard, but this is
important as this is something that possibly is affecting everyone but
other hw is fast enough to hide it...
in the meantime find and optimize what i find along the way.
@optimize
this adds eina_freeq api's for c land for deferring freeing of
pointers and can be used a s a simple copy & paste drop-in for free()
just to "do this later". the pointer will eveentually be freed as
eina_shutdown will free the main free queue and this will in turn free
everything in it. as long as the main lo0op keeps pumping things will
og on the queue and then be freed from it. free queues have limits so
if they get full they will clear out old pointers and free them so it
won't grow without bound. the default max is 1mb of data or 16384
items whichever limit is hit first and at that point the oldest item
will be freed to make room for the newest. the mainloop whenever it
finishes idle enterers will add an idler to spin and free while idle.
the sizes can be tuned and aruged about as to what defaults should be.
this also allows for better memory debugging too by being able to fill
freed memory with patterns if its small enough etc. etc.
@feature
test_efl_ui_text was creating a very small window,
with cropped components, etc.
So let's create it with a mininum size to be able to
properly see this test.
This series adds support to Framebuffer on Ecore Evas VNC.
So both X11 and FB will be supported by Ecore Evas VNC and
may be used to map remote clients as multiple seats.
Patches by Guilherme Iscaro <iscaro@profusion.mobi>
Differential Revision: https://phab.enlightenment.org/D4373
it was using old API, updated, but still doesn't work as expected,
lots of warnings from children being left alive, all proxies are
reporting no properties...
when model dies, all children proxies should die as well, otherwise we
get on console:
```
CRI:eldbus lib/eldbus/eldbus_core.c:215 eldbus_shutdown() Alive TYPE_SYSTEM connection
ERR:eldbus lib/eldbus/eldbus_core.c:175 print_live_connection() conn=0x8219230 alive object=0x8276d50 net.connman of bus=net.connman
...
```
Also, all proxies are reporting no properties "(no properties yet)",
likely they are missing to fetch such... even if "--wait" to let it
run, no asynchronous properties are delivered, at least not triggering
EFL_MODEL_EVENT_PROPERTIES_CHANGED.
remove setters that do not make sense, they are set in the constructor
functions and cannot be changed.
define the Eldbus_Connection_Type in .eo, properly type functions
using it.
Transit zoom effect didn't care image fill area in case of manual filling.
This additional logic computes map uvs with regards to the current image fill area.
@fix
Evil implementation of pipe() function uses sockets. Windows functions
"write", "read" and "close" doesn't works with sockets. In this commit
added macros, that replace "read" with "recv", "write" with "send" and
"close" with "closesocket".
@fix
The first patch did not work for maps. This explains why the
original code was so weird. But it actually made sense.
After struggling a bit I realized that we really just need
to shuffle around the pixel position on the window to map that
of the position in the canvas (unrotate it).
Note that compatibility with GLSL-ES (for OpenGL ES) implies
we can not use an array initializer like:
vec2 pos[4] = vec2[4](a,b,c,d);
So the code could probably be optimized. But at least this works.
This patch also avoids calling glGetUniformLocation again and
again.
Stefan Schmidt
Subhransu Mohanty
Carsten Haitzler
Daniel Zaoui
Stephen okra Houston
Bruno Dilly
Guilherme Iscaro
Daniel Kolesa
Gustavo Sverzut Barbieri
Hermet Park
Mykyta Biliavskyi
Jean-Philippe Andre
Cedric BAIL