Now the gadget show EXACTLY the same values of the free command on my machine,
but note: I found at least 3 different implementation of procpc so your values could be a bit different.
this shortens logout timeout for "apps still hanging around" to 3
seconds meaning that within 3 seconds something should complain that
logout is taking too long so you know your logout request actually
went through... and any app not responding in 3 seconds is likely
"bad" (swapped out, hung on blocking i/o or something or doing a "are
you sure" dialog thing).
It's hard to mimic "free" output parsing /proc/meminfo... we should really use sysinfo.h
directly (like free does).
btw, on my system now the values are really near the "free" output
Summary:
The problems were that both sysctl implementations defined public accessable fields named bat.
The static definition moves into the file scopes.
The E_FREE calls are fixing a use after free.
Reviewers: zmike!, bu5hm4n
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4629
It now show lots more usefull information.
The actual values still need to be adjusted, the goal is to show the exact same values of the "free" command
keys of pointer hashes are represent as void** so you just get a pointer
to where the pointer can be found. This now dereferences the pointer so
the correct value is used.
This fixes T5136.
* collect more info than just 2 percentage
* improve performance by parsing proc only onece every loop
* use active memory to calc percentage, now the value is near the other mem tools I have
this should keep the perfromance of the prior commit
f80f73a7c9 and now get quality back by
generating thumbnails at higher resolution then scaling down from there.
@fix
bgp[review uses livethumb. livethumb by definition uses an image
canvas with a sw engine and thus not only renders the bg with another
engine, it also is causing continual texture uploads thanks to the
pager and this shows clearly on slow systems. this causes memory
duplication for the same wallpaper as ever bg has its own canvas and
buffer etc.
this does come with a quality drop though and that's up for debate. we
COULD use something else like a proxy or map in between to force a
higher "virtual" res vs output. but for now at least this solves both
a memory bloat issue and a performance problem.
@fix
==15191== Invalid read of size 8
==15191== at 0x2B6328A7: eina_list_next (eina_inline_list.x:32)
==15191== by 0x2B637520: _bar_empty (bar.c:1405)
==15191== by 0x2B639301: _bar_recalculate_job (bar.c:1958)
==15191== by 0xDBDA800: _ecore_job_event_handler (ecore_job.c:98)
==15191== by 0xDBD3AC6: _ecore_call_handler_cb (ecore_private.h:317)
==15191== by 0xDBD4A55: _ecore_event_call (ecore_events.c:518)
==15191== by 0xDBDDABF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==15191== by 0xDBDB86D: ecore_main_loop_begin (ecore_main.c:1290)
==15191== by 0x441A94: main (e_main.c:1093)
==15191== Address 0x1ff97dc8 is 6,520 bytes inside a recently re-allocated block of size 8,192 alloc'd