so our writes sometimes would get stuck because kernel io buffers are
full and writes are slow. on specific machines with super slow write
media and small amounts of ram this was bad.
this moves writing totally to threads. the eet file is opened in a
thread and closed in the same thread. only the eet_write/eet_data_write are
done in the mainloop. this is a 'walk struct, serialise it and compress
it" which compared to blocking for possibly multiple seconds in a
write/close/rename backup cfg files doing real io to kernel 9even
though kernle should buffer these)... is a hell of a lot better.
so sure. we block lock enough to walk the structures/lists, encode the
blob and put it through a fast lz4 compress cycle and drop into memory.
the actual write happens in the thread when the file is closed and
that is a vast improvement if you hit these cases.
in some cases, eg., -Wformat-nonliteral, warnings may be generated for
valid uses of C, but the warning is still useful. this allows certain warnings
to be disabled as necessary
so every time i restart e i have my windows all messed up. it's
INSANELY annoying and time consuming every single time having to move
a dozen or more windows back to where they should be just because i
restarted e. i've narrowed it down to 2 places. 1 which is trying to
handle "out of screen" windows and during startup it seems things are
not quite stable yet as the randr code figures things out until the
event storm settles down.
when this is then fixed - another bit of code just shuffles windows up
all the time by a titlebar whcih is also supremely annoying. this is
the code that adopes a new frame for a window.
so the nasty hack to avoid piles of pain right now is for the first 5
seconds of e's life - don't do this stuff. at least you can now use e
and not be annoyed to hell and back every restart.
yes a nicer fix may be better - but that's going to take a lot more
time and patience and until then - this will do.
this follows 56cabf59c6 then
4e5521b4d8 where i have been trying to
fix a crash with e client and comp win references etc. i have gone
over all referencing with a fine tooth comb and found all the nigglies
i can., no leaks now, no crashes, no valgrind complaints etc. so i
call this fixed now. as best i know this is new in e20, so not a
backport fix
str(n)dupa are GNU extensions that duplicate a string, using an alloca'd
buffer. This patch removes their definitions from e.h (which should only
contain E's own API, without fallback definitions for libc functions)
which were wrong anyway (they failed in cases where str(n)dupa was an
actual function, not a macro).
Instead, we replace them depending on context with alloca+memcpy+strlen
or a static buffer (used in contexts where we are sure that the buffer
will contain the string entirely)
@fix
so e is using eo... and something in eo changes... and e fails to
compile entirely.... there are hacks to use eo... and this is not good.
eo is still in a beta state. that means any usage of it can (and
will) break. this is a problem for e. if e uses eo, then eo breaks in
an efl upgrade, e breaks. we can't really have that. we already hit
this problem in terminology with the app server code in elm. so let's
just not use eo in e until it's stable.
this removes eo usage in all places, with the e_menu code having a
small isedje() func due to some of its code paths doing special things
based on if the obj is an edje one or not as opposed to just a simple
"only emit if its an edje obj".
Instead of rolling our own we go with a known working UUID implementation
here. Dependency should be easy enough as more or less every Linux system
is shipping it anyway.
this is crazy. all the E_OBJECT_CHECK macros have been off since 2007.
this is just nuts. either remove them, or have them on by default, but
not off. so this turns them back on and fixes code to actually compile
again with them on, as this broke over the years. a lot of code
expects/assumes thatthese willcheck types and null ptrs, but they
don't because they are off by default.
This reverts commit 91b3f2e0e1.
revert wars part 4: the blizzard blitz!
the main point of freezing idlers here was not, in fact, to optimize, but to block an infinite loop which pegged the cpu until screensaver ended. this solution should be less issue-prone for the one person who had issues with the previous fix.
this was pretty old/legacy and looked like it would fall over pretty easily. there's no users and I see no use for it, so it goes bye bye
removals: e_main_idler_before* api
* try to clear up build system for separating out ecore-x
* add #ifdefs for lots of ecore-x stuff
* break out some internal e wl functions for reuse in api
* store wl surface buffers as an inlist
* add protocol-specific client compositor data
** move lots of X client attributes here
* add pixmap type checks to a number of X-specific things, such as grabinput, to block them for non-X clients
* rearrange startup order to work with wayland
* move X screensaver code to e_comp_x
* flag modules still requiring X with -DNEED_X
provide a config upgrade path to version 13 which nulls/frees out
theme config (save memory - but more housekeeping), and that also
copeis ofer all files in ~/.e/e/themes to ~/.elementary/themes so you
don't lose themes you personally have and deletes the old e theme dir
if this succeeds.
also remove all #includes of Elementary.h and Emotion.h from single c
files as they are requirements now and in e.h
also remove theme path vars and code as theme path is no longer used.
* remove xwin for container canvas: now drawn directly on the compositor canvas
* added SHAPE_DEBUG define for bored developers
* bindings now use new e struct for mouse/wheel events
* container+zone now get mouse events from smart callbacks instead of x events
* rename comp api namespace
* change comp underlay theme to have a swallow for the wallpaper
* add names to all zone/container/comp objects to make debugging much easier
* some minor related updates to go along with this
SVN revision: 83752