This patch adds some stuff for smart callback description/instropection, which
is still untested but doesn't break anything that's out there now. Should help
with bindings later on.
Also some parenting guidelines for smart objects, so it's easier to spawn a
subclass out of another. Look at Box and Table for an example on this.
And again, rebuild everything that uses smart objects after this update, or
the world will turn into a happy place where lawyers are no longer needed...
and we don't want to upset the lawyers.
SVN revision: 45043
Evas image load was always reporint "generic" error, since it was
disconnected from actual loader modules.
This commit will break the module loader API (as it's restricted to
inside Evas, this should be no problem). The return was turned into
"Eina_Bool" for clarity, while an extra "int *error" is responsible to
report errors. This approach was choosen to force compiler warnings
and to try avoid mistakes as EINA_FALSE == EVAS_LOAD_ERROR_NONE and
thus we'd get opposite behavior if something slips.
Most loaders play well, except by eet that does not provide means to
know if the file open failed due missing file, incorrect format or
corrupted file :-(
Please report any issues. I added eina_log debugging to loader
functions, just run your Evas application as:
EINA_LOG_LEVELS=evas_main:4 your_app
SVN revision: 44666
This code should be cleaner and easier to understand. It also provides
the ability to spread image decompression on all CPU core. I currently
set it to the exact number of CPU core you have in your machine, if you
find case where it slow down your EFL apps too much, we can reduce this
to give at least one core to evas.
All previous bugs related with async preload are gone, hopefully no
new one are in. Please report any problem with backtrace to me.
SVN revision: 44537
changed. still renders all, but better now. keeps map surfacer around for
shits and giggles until map unset or object deleted. als be able to set
smooth map and disable alpha (for smart objects)
SVN revision: 43362
change evas_map to return a structure that serves as an array of
points. This way we'll know for sure the number of points in it. Right
now it's hardcoded to 4, so check it, but in future we can just allow
more points and it should work.
added docs. I'm not sure about most of it, so it would be good to have
someone to review and fill in more, maybe that's raster? Grep for
"TODO" and you'll see the missing stuff. It would be good to add
examples in evas_map_point_coord_set() and
evas_map_point_image_uv_set()
SVN revision: 43211
Hey raster,
Here is the non intrusive patch I talked to you about. Please apply it as it
introduces some fixes, some improvements and mostly and underlying
infrastructure for future RTL improvements.
(note hebrew & yiddish seem fine, but things expedite test seems to show are
wrong (why i don't know as i dont speak the langs- just comparing to pango /
gtk output):
arabic seems lsightl wrong (maybe composition chars not working?)
gujarati - also seems wrong
malayam - also looks wrong
persian - looks wrong
sinhala - looks wrong
tamil - looks wrong
these are what, appear to me, to look wrong. why they look wrong, i don't
know. i'm guessing its compositiong not being handled. but i dont's peak,
read or write any of these languages so i am unsure of what it really should
be like, why and how to fix it.
anyone want to put up a hand? (everything else is displaying fine as best i
can tell - the langauges i read/speak/somewhat understand are working fine).
SVN revision: 42814
- Forgot to reset clip before drawing cleanup rect.
- Always draw a rect to reset the background, just
choose a correct color.
Note: This will slow down software_x11 engine, as this engine
always do memset, so it does it twice. Before only the alpha
case was impacted, now both case are. Need time to fix it. If
someone has, don't hesitate :-) You can use elementary windows
state test, to see if thing is going correctly or not.
For the record, SDL engine has a score around 500 under X11 on
my computer, where the X11 engine does only have a score around
450.
SVN revision: 41770
Improvements: Now evas rendering loop is the one responsible to
initialize the surface to 0 correctly (taking into account surface
alpha and object opacity). This will reduce the number of memset
we do.
Note: Current software_x11 (xlib and xcb) are buggy. They are
copying too much data when the surface use a mask. That's why
two memset are left in their code. They could be removed, but
we should fix the surface we copy on change (look at mxob user
and evas_software_xlib_x_output_buffer_paste).
SVN revision: 41206
also rename evas_layer_free() to evas_layer_free_objects() as what it
do now, make _evas_layer_free() as static and use it both cases.
SVN revision: 41123
the parent.
When we insert object inside a smart object, they could be attached to
another layer. As long as ref counting work, nothing wrong will happen.
But during destruction of an Evas, we were just looping over all layers,
destroying each of them, without checking for refcounting. This could
cause SEGV.
This patch introduce a third loop for wiping out all layers after
destroying all Evas_Object. So no more SEGV, and no performance
regression.
Note: Do not rely on evas_object_layer_get on smart object's child, it
could give you the wrong answer.
SVN revision: 41046
none (ie default) and the engines actually understand it and use it.
2. fixes to scalecache and cserver too. more toto's done and its now been
stress tested by me - and i think cserve is ready to go gold. just enable it
with export EVAS_CSERVE=1 in your env for any eflapps - and run evas_cserve
(cmd-line options avalable plus cmd-line tol to query settings change on the
fly and query statsitics and state)
SVN revision: 40536
is it ok?
1. it can be --disabled in evas's configure, but i think it works WITHOUT
disabling it (runtime) as it falls back to the old way of loading
2. it may cause build problems on some platforms - without it being enabled
we won't find out, so enable.
3. it needs enabling runtime to make use of it so it should be safe for now
until you enable it.
what is it?
it is a SHARED cache server - that means images loaded are loaded BY the
cache server (not by the actual process using evas). images are shared via
shared memory segments (shm_open + mmap). this means only 1 copy is in all
ram at any time - no matter how many processes need it , and its only loaded
once. also if another app has already loaded the same data - and its in the
cache or active hash, then another process needing the same stuff will avoid
the loads as it will just get instant replies from the cache of "image already
there". as it runs in its own process it can also time-out images from the
cache too.
right now you enable it by doing 2 things
1. run evas_cserve (it has cmd-line options to configure cache etc.
2. export EVAS_CSERVE=1 (im the environment of apps that should use the cache
server).
it works (for me) without crashes or problems. except for the following:
1. preloading doesnt work so its disabled if cserve is enabled. thisis
because the load threads interfere withthe unix comms socket causing
problems. this need to really change and have the cserve know about/do
preload and let the select() on the evas async events fd listen for the
unsolicited reply "load done". but it's not broken - simple preloads are
syncronous and forced if cserve is enabled (at build time).
2. if cserve is killed/crashes every app using it will have a bad day. baaad
day. so dont do it. also cserve may be vulnerable to apps crashing on it - it
may also exit with sigpipe. this needs fixing.
3. if the apps load using relative paths - this will break as it doesnt
account for the CWD of the client currently. will be fixed.
4. no way to change cache config runtime (yet)
5. no way to get internal cache state (yet).
6. if cache server exist - it wont clean up the shmem file nodes in /dev/shm
- it will clean on restart (remove the old junk). this needs fixing.
if you fine other issues - let me know.
things for the future:
1. now its a separate server.. the server could do async http etc. loads too
2. as a server it could monitor history of usage of files and images and
auto-pre-load files it knows historically are loaded then whose data is
immediately accessed.
3. the same infra could be used to share font loads (freetype and/or
fontconfig data).
4. ultimately being able to share rendered font glyphs will help a lot too.
5. it could, on its own, monitor "free memory" and when free memory runs
load, reduce cache size dynamically. (improving low memory situations).
6. it should get a gui to query cache state/contents and display visually.
this would be awesome to have a list of thumbnails that show whats in the
cache, how many referencesa they have, last active timestamps etc.
blah blah.
please let me know if the build is broken asap though as i will vanish
offline for a bit in about 24hrs...
SVN revision: 40478
remove last code using non-eina_mempool rectangles and abort() that
was triggering on clicks on titlebar.
Thanks to antognolli for reporting.
SVN revision: 40074
we change cur.geometry in the code (did a grep to locate this). I hope I did
spot all users, as I didn't see bug in exec_buf, efm and in window title, I
am confident enought to break svn again.
* WARNING * This change can cause visual bug. Please report.
SVN revision: 40039
why it was disable the first time, so it could lead to some graphic bug.
Please report any strange behaviour.
*WARNING* This could really introduce some visual bug.
SVN revision: 39940
* evas_engine_info_set() returns now an int, to inform if
an error occured or not when setting the info of the engine.
* in the Evas_Func structure, the setup() method returns an int
* all the engines are updated
I'll fix ecore_evas and ewl later (the compilation is still fine).
Gustavo: should I add EINA_WARN_UNUSED_RESULT at the end of the
evas_engine_info_set() function ?
SVN revision: 39670
**** WARNING ****
E is bugged in some place, it does swallow object from another Evas in some place.
With this patch, it will abort sooner. If you find situation where it abort, please
report. This are nasty bug hidden in our code base. And yes, you will the white box
of death, this is expected.
SVN revision: 39528
* mainly unused parameters
* in src/lib/imaging/evas_imaging.c, set font to NULL
* in src/lib/canvas/evas_object_gradient.c, add unititialized member
there are a *lot* of reported warnings by llvm, i'll fix them later
there are also *lots* of unused parameters (compile evas with -W). I'll
fix them later too
SVN revision: 39172
For some unknown reason evas was informing EVAS_CALLBACK_* even if the
original call did not changed the internal object state, that is, new
value is already equal to current value.
This is specially costly since Edje, Box, Table and possible other
layout engines will call evas_object_resize(), move(), show(), hide()
even if the state has not changed, assuming evas will ignore the call
(as it does). The real overhead might come if there are listeners
attached to these events, that in turn might do lots of other stuff,
leading to a torrent of useless calls.
I marked it for removal, please test it and uncomment '#define
CALLBACK_NOOPS' to get the old behavior back. It does seems to work
with e17 and edje_editor. If problems appear, let's try to fix the
real problem instead of getting this code back, it's a performance
penalty.
SVN revision: 38955
evas_object_image_preload() should not use object as const because it
will mdofiy the object state (so it's semantic makes more sense).
if data was already loaded, then callback before ignored it (return).
SVN revision: 38246
fast direct3d engine written by Dmitriy Mazovka. You rock !
* m4/evas_check_engine.m:
* m4/evas_check_loader.m4:
use m4_popdef for each macro (otherwise, fail if aclocal is too old)
* src/lib/canvas/evas_font_dir.c:
include evas_common.h and evas_private.h after Eet.h and Evil.h
so that EAPI is correctly defined
SVN revision: 38244
if image was already preloaded, inform user.
regular use case is to have image hidden, ask for preload and then
show image on callback, if there is no callback, image is never shown.
SVN revision: 38236
Wow, this was tricky to find since it is hard to trigger, thanks to
Canola complex edje files we could spot it!
In some cases we end with object being marked as dirty while
calculating its state (ie: edje), then we need to run smart calculate
again.
This has a drawback however: we cannot check for need_recalculate()
inside smart calculate anymore, we must assume it is only called if
the flag is set. To avoid that we could mark a shadow member and use
that or use a counter, that has the problem of using more data.
SVN revision: 38108
Unset value is now 0x0 and this is handled as invalid, with an error message.
1x1 is a valid fill, but it is very slow and often system hangs while
it scale the whole thing... usually nobody want it at 1x1, we just end
using that for unset values. With unset value at 0x0 it will not
happen and we'll know when we forgot to do so!.
SVN revision: 38071
* group the want_* variables related to engines and loaders at the beginning
of configure.ac
* use -no-undefined directly instead of a flag checked wrt the host
* some clean up in Makefile.am files
Please report any problem
SVN revision: 37784
giving an extra void *user_data to layout function is now easy to
write bindings, just give the callback to be a generic function that
will call the language/binding specific function handled as user_data.
Example, for python we can use:
void _layout_dispatcher(Evas_Object *o, Evas_Object_Box_Data *priv, void *data) {
PyObject *pyobj = data, *args;
args = PyTyple_New(1);
PyTuple_SET_ITEM(args, 0, Evas_object_from_instance(o));
PyObject_Call(pyobj, args, NULL);
Py_DECREF(args);
}
evas_object_box_layout_set(o, _layout_dispatcher, pyobj, Py_DecRef);
SVN revision: 37640
Carsten Haitzler
Vincent Torri
Cedric BAIL
Sebastian Dransfeld
Iván Briano
Gustavo Sverzut Barbieri
Jonathan Atton
Tom
Christopher Michael
Andreas Volz
Viktor Kojouharov
Davide Andreoli