automake was "smart enough" to include in DIST_SUBDIRS even when 'if'
clause didn't add it to SUBDIRS, that was causing modules like XPM be
added twice, resulting maintainer-clean to double-clean the directory
(one from src/modules/loaders and other from src/lib), failing on the
second time.
SVN revision: 41060
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
the connection from the fork (the cserve connection). it won't catch
threads... most of the time, but i need something else for that i think.
SVN revision: 40869
* fix the way AC_INIT macros are parsed to consider [] as well.
* set both LDFLAGS and CFLAGS on the libs I use and I know support -fvisibility=hidden.
SVN revision: 40838
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
- don't package directfb, it's for specific systems like embedded
where it is required to build manually, maybe define some tweaks.
- don't build with no-dither-mask as it will completely disable
dithering on 16 and 8bpps, that's wrong! This is supposed to be
enabled on embedded devices only, like maemo.
SVN revision: 40518
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
2. yes local.conf slipped in - ignore
3. added soname version release to module arch dirs
4. adapted extra-modules to use the revision in arch
5. made e17 also have a release rev
6. dummy release stuff in eet - wont use it as its already released.
SVN revision: 40267
Do NOT include dirs in EXTRA_DIST (embryo, eet, ecore, evas, edje,
efreet) as it will include .svn directories!
EXTRA_DIST does not take a glob as ETK did, use $(wildcard glob) to
expand it.
And do not forget about adding extra files to EXTRA_DIST (wizard) and
DIST_SUBDIRS (fileman_opinfo).
SVN revision: 40247
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
this (apparently) makes right-to-left work for display. that means:
hebrew
yiddish
arabic
persian
...
i don't read (or write ... or speak) an of these...
so.. i'll leave it up to others to find bugs/problems and send patches.
thanks a huge amount to TAsn for the patch!
SVN revision: 39972
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
dunno why, but at least it does for me and some users at #e/#edevelop,
e17 freezes at start, so does canola and other evas apps, maybe due
64-bits? No time to investigate right now (at a conference).
SVN revision: 39738
enabled. the blending is not working/complete. the neon for fills and copies
isnt actually faster though currently :(
2. scalecache infra - disabled for now. working on it.
SVN revision: 39723
* 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
let's stop replicating these macros over and over again, also flag
evas functions with attributes to help with optimizations.
TODO:
* move functions returning "int" as boolean to Eina_Bool
* move api entry to EINA_SAFETY_*
* document api
SVN revision: 39598
**** 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
The behavior of AC_CHECK_HEADERS is a bit strange: If one has
2 header files foo.h and bar.h and foo.h exists while bar.h
does not, then:
1) with
have headers="no"
AC_CHECK_HEADERS([foo.h bar.h], [have_headers="yes"])
the value of have_headers is "yes"
2) with
AC_CHECK_HEADERS([foo.h bar.h], [have_headers="yes"], [have_headers="no"])
the value of have_headers is "no"
SVN revision: 39479
uses the same mutex macros used by the mutex on font objects, so it makes it
a bit simpler. old code is commented out for reference.
SVN revision: 39458
* 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
2. make gl engine able to use cutouts - in some cases its faster, some
slower. it's a mixed bag. not sure what to make of it. it's #defined to be
disabled atm.
SVN revision: 39114
* evas/src/lib/engines/common/evas_font.h,
* evas/src/lib/engines/common/evas_font_draw.c,
* evas/src/lib/engines/common/evas_font_load.c,
* evas/src/lib/engines/common/evas_font_query.c: Add cache for font kerning.
This patch give something around 2% for all tests around text in expedite,
except for Textblock Intl where it give a 3 times boost.
Regarding text rendering speed, something is strange when used by evas_pipe.
All tests using Styles are around 40% faster without evas_pipe. 30% faster
for Text Change. But Text Basic 7% slower. So it should be possible to have
faster rendering when using evas_pipe for font rendering.
SVN revision: 38993
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
If one want to load image at a given height or width and the other
dimension should be large enough to make it possible, give -1 as the
other coordinate and this will happen.
SVN revision: 38845
we should just remove entries pending preload from the cache being
shutdown, not all of them.
this is untested as it is hard to force this situation, but should be
more correct than the previous.
SVN revision: 38747
before, when no more images were to be preloaded asynchronously, the
thread exited, but were not collected. This leads to a huge leak if
the process is doing aggressive use of image preloading (ie: photo
wall).
collecting dead threads in a proper way (read: without race
conditions) is a bit harder than keeping just one thread alive,
forever. As we do that for evas_pipe (the renderer), let's do the same
with preload and save code.
SVN revision: 38746
users of buffer engine (ie: e_thumb_main.c) were broken since when
they resize the canvas they would implicitly call engine->setup()
again, which would destroy output and create it again. However the
cache could be destroyed and images using it would be bogus.
This does not happen if the process have other cache users, but
e_thumb is just one canvas live at time.
By reordering, we have the cache reference to go to 2 and then back to
1, not destroying it.
SVN revision: 38739
1. get rid of grammar mistake
2. refer to COPYING-PLAIn correctly as the filename
3. be more explicit on "shipping source" due to ambiguity (this makes it what
it was intended to be and that is GPL compatible).
this does not modify the LGPL libs... or GPL apps etc. - only those using the
original COPYING from e. author and dates at the top remain the same.
SVN revision: 38569
1 - use inlist as regular list uses non-thread safe mempool;
2 - lock around image loading, so if main thread requests pixels right
before worker thread is loading them, you don't get ie->info.module
to NULL while it would be used (triggered from engines/common).
Maybe this should be handled by a global mutex elsewhere instead of
per-image mutex, but it has more granularity now.
3 - emit "preloaded" callback if it was canceled to be loaded from main
thread.
Please someone review these changes.
SVN revision: 38312
image preload will use modules from threads, there is a possibility to
crash due wrong reference counting.
actually much more can fail, we need to check modules don't keep that
needs exclusive access in globals or per-Evas_Module, but that's
another issue.
TODO: replace spinlocks with atomic operations.
SVN revision: 38309
We had some problems with preload and after running LLVM's CLang
Static Analyser we found out that current->target could be NULL after
loop.
Also fixed some GCC and CLang warnings, kudos to these wonderful tools
that "Saved The Day".
PS: we should put some CLang Static Analyser results so others can
help fix other parts of E.
SVN revision: 38293
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
Eina hash api must get non NULL pointer allocated with
eina_hash_new(), but Evas hash started with NULL and would allocate
and destroy the hash as required by operations.
To do a proper wrapper we must ensure we don't call Eina hash API with
NULL, we must handle that outside Eina.
PLEASE do not remove this code again (it's the second time I add it),
this is the correct approach. Other than that is going after evas_hash
usage and converting directly to eina_hash.
SVN revision: 38091
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
* evas: if we automatically destroy hash, check for NULL before
handling it to eina api, which expect elements to be created with
eina_hash_new() and thus will fail on NULL.
* eina: add magic checking for eina_hash and eina_hash_iterator, this will
help spot when NULL is used.
* eina_hash_foreach: do not try to create the iterator if hash is NULL.
SVN revision: 37982
* 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
but some other people can help me now with that code in svn
* expedite is working but sometimes crashes. Maybe a big mem leak ?
* maybe moving the creation of the bitmap in
evas_software_wince_gdi_output_buffer_paste()
to
evas_software_wince_gdi_output_buffer_new()
so that the memcpy is not necessary anymore
SVN revision: 37709
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
* when fopen used, open in binary mode
* use Evil when fopen is used
* clean a bit some Makefile.am and add Evil dependency where needed
* in evas_path.c, remove useless old Windows CE code. It's managed by Evil, now
* in Evas_Data.h, move Eina.h before EAPI is defined for Evas.
* define _WIN32_WCE when the host is windows cee
SVN revision: 37476
tyo fix up some of these breaks first and there isn't a lot of time devoted
to this. so revert this. it's in svn history so we can dig it out any time we
like.
SVN revision: 37453
1. nearest scaling is now broken - it's always linear interpolation. this
will lead to slowdowns. i need to fix this - a must.
2. i think it's time i put in a transformed image cache that can cache an
image object at a transform (and share it) automatically.
3. transforms in non-software-engines will not work - broken. need to at
least do xrender and gl engines.
any volunteers to help?
SVN revision: 37447
Table code is still *incomplete*, it just do homogeneous layouts as
I'm still trying to figure out how to make it great.
I'm not expecting to make layout configurable, as we did for box, but
if you think it's required we can do that later.
Now that the public API of both BOX and TABLE are in, we can add these
as parts of Edje.
SVN revision: 37359
Draw back: When we are destroying an Evas canvas, we loose all cached font
that are not used anymore.
A correct fix would be to link Fndat to the Evas that provide and use them.
And only delete them when no more Evas reference them.
SVN revision: 37353
Box is a smart object to help with the common task of laying out lots
of objects. It's very flexibile and one can customize the layout
function on a per-object basis dynamically, just set a new layout
function (the most common are provided). By default layouts use size
hints from children to do their work, but one can also add new
properties, just subclass with evas_object_smart_smart_set() and then
define your own option_* callbacks.
This code was ported from Guarana (widgets/sequence_box.c) with
permission of ProFUSION embedded systems so it can be relicensed from
LGPL to Evas license.
Original author: Gustavo Lima Chaves <glima@profusion.mobi>
Port: Gustavo Sverzut Barbieri <barbieri@profusion.mobi>
SVN revision: 37188
On the let's break 'em all bandwagon, add the two callbacks (or
virtuals if you like the name) so we can know when some object is
attached or detached as a member of our object, this will help
eliminate confusing and duplicate functions like
evas_object_smart_clipped_smart_add().
Please recompile *ALL* your libs and applications that depend on Evas
and Smart Objects, like ETK.
SVN revision: 37084
565. what it does is it's a half-way house between no dither and "small
dither mask". what is does is change the "rounding" between odd and even
lines. the resolt is not as nice as small (or large) dither mask - but its
almost "good". it gives a horizontal-blinds like look to dithering. it's
almost as fast as no-dither in my tests on a core2 (of course making lots of
use of branch prediction or conditional instructins - whihc arm nd x86 have).
SVN revision: 36373
ProFUSION funded the rework of DirectFB engine, it works quite well,
please report problems with it and be sure to try to uncomment the
following lines to see if it helps:
evas_engine.c: (uncomment if you notice problems)
//#define DFB_USE_EVAS_IMAGE_DRAW 1
//#define DFB_USE_EVAS_RECT_DRAW 1
//#define DFB_USE_EVAS_POLYGON_DRAW 1
//#define DFB_UPDATE_INDIVIDUAL_RECTS 1
polygon.c: (comment if you notice slowdowns, but may lead to visual problems)
#define USE_SPAN_RECTS 1
You can also turn on debug by uncommenting in evas_engine.c:
//#define DFB_DEBUG_IMAGE 1
//#define DFB_DEBUG_FLAGS 1
//#define DFB_DEBUG_ACCELERATION 1
Thanks to Denis Oliver Kropp (dok) for review and patches!
SVN revision: 35904
that's about it. a bit hacky - but works and frankly.. the idea is that u'd
set a scale factor once really and not change it per obj... most likely.
SVN revision: 35896
This class covers the most common cases, usually its sub-classes will
have to implement resize and override one or two methods at most,
making the smart object usage less error prone and easier.
Default behavior is:
- add: creates a hidden clipper with "infinite" size;
- del: delete all children objects;
- move: move all objects relative relatively;
- resize: not defined;
- show: if there are children objects, show clipper;
- hide: hides clipper;
- color_set: set the color of clipper;
- clip_set: set clipper of clipper;
- clip_unset: unset the clipper of clipper;
Documentation explains an easy way to inherit from this class and
still be able to use overridden methods.
SVN revision: 35861
Some people is using it for some time now without problems, so I'm
adding it to SVN to get some broader use. Remember to recompile ALL
libraries that depend on Evas as it will change the
EVAS_SMART_CLASS_VERSION and old classes will fail to load.
This will also change Edje so it will postpone _edje_recalc() to
render time, calculate() callback, however some methods will force
early recalculation.
SVN revision: 35860
- some enignes break as they dont have the stubbed out functions, and
xrender/gl engines dont even implement the drawing and need to (but are
stubbed out).
SVN revision: 35677
* add a ressource file that set the video management
as non legacy. It forces device that are in vga to
run in vga and not in qvga with gapi
* use c++ calls to display error messages in evas_wince_ddraw.cpp.
It removes a problem during linking with some versions of cegcc
* minor fixing / formatting
SVN revision: 35148
pthread manual says it is safe to destroy them after they are used
with pthread_create: "If the attributes specified by attr are modified
later, the thread���s attributes shall not be affected."
SVN revision: 34937
This will check both function and data before removing the callback,
this is useful when you have lots of children monitoring parent, when
one child want to remove its monitoring function, others will remain.
Name is quite difficult to choose, I opted for "_full", but could be
"_with_data" or similar.
SVN revision: 34731
Image_Entry flag structure. This fix a bug with 16 bpp software engine.
* Change image loader module API to take any Image_Entry. Same goes
for evas_common_image_premul and evas_common_image_set_alpha_sparse.
* Use new eet API: eet_data_image_read_to_surface.
SVN revision: 34728
totally done and may hand control back to a non rendering codepath - or
before u do any fp ops u are unsure of the cpu state beforehand. see the big
fat comment.
i was right. it was a missing emms.
SVN revision: 34707
the buffer one at first (always compiled), then Xlib ones, XCB ones,
Windows ones, followed by others less used (SDL, FB, Qtopia). I
let the 16 bits ones at the end in the same order (Xlib, Windows, SDL).
SVN revision: 34690
* remove printfs that clutter output
* add efreet file type check - only parse regular files
* chekc mmap returns correctly for MAP_FAILED results
* edje has some stubs for adding script-only objecvts - but nothing useful
right now
SVN revision: 34689
This patch fixes the problem with bitfield of signed types (ie: char),
where the bit would be used for the signal, so 1 is considered -0 and
thus 0.
Move all the single bit fields to Evas_Bool, making it clear and also
avoiding these problems since Evas_Bool is unsigned char.
SVN revision: 34631
2. free then malloc otherwise realloc might ALSO have to memcpy if it cant
resize the segment whihc means overhead we dont need/want.
SVN revision: 34441
By having a layer as a short (16 bits) we can pack it together with
the bitfields, saving 4 bytes per sub-struct, 8 bytes in total, also
bringing the struct down from 4 to 3 cachelines on my laptop.
Rationale: layers are mostly used to differentiate groups of objects
and they stacking, usually we have few layers and we use very large or
very small numbers to make a layer be at the top or at the bottom, but
usually we don't need so many layers.
Caution: code that use values like 999999 will break, so fix your
code! I'll provide another patch to fix all the CVS using these large
values.
SVN revision: 34420
This saves 20 bytes, bringing Evas_Object to 200 bytes, by moving data
specific to smart objects to their own struct (Evas_Object_Smart).
There is still one remaining member that could be removed:
smart.smart, this is used mainly to identify if one object is a smart
object or not. One possibility would be to add a bitfield to state
that, but another possibility is to check Evas_Object::object_data
and see if it's a smart or not.
SVN revision: 34419
Interpolation color_space (now ASHV or ARGB) was being used inside a
struct with 4 byte alignment. Remove it from the struct and make it a
bitfield so can be packed with the other fields. This saves 2
integers, so 8 bytes.
SVN revision: 34418
This is a repack of bitfield members, was tested on GNU/Linux + GCC 4.1.2
and works fine. Needs further testing on other compilers.
SVN revision: 34417