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
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
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
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
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
* 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
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
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
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
- 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
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
* 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
The engine is not entirely working right now. Recent devices which
supports the raw frame buffer should work though. But having it in
cvs will help me as I'm coding it most of the time "blindly" (no
device to test it)
* minor formatting in the top evel Makefile.am too
SVN revision: 34354
* formatting
* put WIN32_CFLAGS in AM_CFLAGS and not AM_CPPFLAGS, as it is where it belongs
* rename create_shared_lib to lt_no_undefined
* pass -Wl,--enable-auto-import to libtool when compiling with cegcc
* add files to EXTRA_DIST only when they are not in _SOURCES or _include_HEADERS (they
are added anyway)
SVN revision: 34353
* Allow Windows Mobile to correctly load dll's
* Use correct scheme for EAPI on Windows and include config.h when necessary
* add -mwin32 to compiler flags when compiling with cegcc
SVN revision: 34024
* use the pixman library for the region code (it is required, now). That
libray can be found in the cairo ftp.
* use the new xcb_image api that is in git repository. There is still a
seg fault occuring because of xcb_image. I'll commit the fix in git
next week.
The performance are not good at all. With expedite, 360 fps compared to
the 470 fps with xlib. I don't know why yet.
SVN revision: 33965
This is an initial cleanup, basically I removed all the DirectFB
accelerated calls and moved it to software common. I do plan to
gradually bring these back later, probably blit, rectangle and line
will come first.
SVN revision: 33835
This fixes the prototype, however it still issues a warning about a
real bug: calling evas_hash_modify() during evas_hash_foreach()
SVN revision: 33710
1. configure/build changes to allow cross-compiling painlessly
2. pager module namespace changes - this was still dirty afdter the namespace
cleanup, so clean it up
3. add a powersave subsystem - doesnt have an "automatic" way to turn on and
off right now, this i think is best provided by modules (that do things like
monitor acpi status's (eg close lid of laptop), AC power status etc. etc.
this allows e to nicely defer "power" expensive actions to avoid disk
spinups etc.
4. move to use the new ecore poller system - discussed long ago as part of
power management/saving issues. now it exists
5. add a canvas idle flush call that helsp cope with the new shm greedy
software x11 engine stuff
6. use the new powersave subsystem where appropriate
7. fix non-zeroed/initted memory access in e_fm_main
8. fix mem leak for e menus
9. remove ipc handlers for changed/removed config values
10. use animaotr not timer for menu scrolls - then menu scrolls obey the fps
config
11. fix up timer/poll happienss of cursor idle stuff
12. remove avoid damage from popups for now - causing problems
13. change battery and temp readouts to b e shorter so they fit
14. pager can emit signals on focus change for mini-windows now
15. temperature module now uses a slave process and uses stdin/out to talk to
it and get output - this makes e smoother as in my expereicne i found getting
the temp on my laptop actually took like 200ms so e "hang" for 200ms while
reading the acpi files - so now the subprocess does it and just writesa back
to e when it gets it.
ecore:
1. add ecore_pollers. see the documentation on them in doxygen comments :)
2. fix timers to only go off when they have to - bug there that made e's
select time out a LOT more than it needed to. defensive coding hid the
problem. now fixed. e should be much more power friendly now.
3. formatting/niceness in ecore_exe stuff
4. some comments on comments with SIGIO ideas vs. select
5. add call to be able to add an idle enterer at the start of the list of
them, not just the end (as has been the default)
6. fix ecore_evas to support auto evas idler calls after 0.5 secs of idle in
all canvases - and to do it right
7. if argb destination - set the shape EVENT shape (to mask out events in
transparent regions much like shape does withotu translucency)
8. in ecore_x add support for the event shape
evas:
1. fix cache to work properly and not just always fill up (as it seemed to
like to think cahce useage dropped below 0 when it didnt and thus just
over-fill)
2. software x11 engine now ONLY uses shm segments - no ximages over the
socket. this ximage hack was there to avoid the 2 round trips involved in
setting up an shm image - now i mitigated that wih an shm image cache pool.
it keeps shm images around and repurposes them for new update regions if
appropriate. this means many fewer shm creates (about 1/100th the number) and
since we recycle the memory less 0 memory page filling by the kernel - in the
end, i recorded about a 10-20% speedup over the old software x11 engine.
simple tests i have seen up to 120% speedups. idle flush now does something -
it frees all the cached shm segments. it has a hard-coded limit of 4mb worth
of shm segments (or 32 segments - whichever comes first) to keep around. once
can never complain much about speedups methinks :). also evas will defer sync
until the NEXT frame is written - this means evas can calculate the next
frame of data while x dma's/copies the images to the screen at the same time
(if you hve a dual core or multi-cpu machnike or your xserver is able to use
DMA to copy image data to the screen/video ram then this should see a decent
speedup).
SVN revision: 33448
can't test it on a GLSL card, so I hope it didn't break anything. If
something is broken, feel free to revert! (but it would probably just be
related to the way it detects GLSL support at l.78 of evas_gl_context.c)
SVN revision: 33242
* use non deprecated version of AC_INIT and AM_INIT_AUTOMAKE
and check the required minimal versions.
* add bzipped distribution archive
* add AC_LIBTOOL_WIN32_DLL
* forbid libtool to check fortran
* compute libtool versioning from the version of the package
* pass the directories based on ${prefix} to the preoprocessor
with the -D option
* replace INCLUDES, wich is deprecated since 2001 by AM_CPPFLAGS
* remove useless -L flags in *_la_LDFLAGS
SVN revision: 32337
Line is a complete rewrite based on my university works. It's much
cleaner than the engine/common and works better (the later is
producing weird results, I still have to debug why), but I don't
provide anti-aliased drawings.
Polygon is almost the same code, with minor changes to draw the spans
as soon as possible and then no malloc/free is required for each of
them.
Minor fixes to remove unused variables, gotos...
SVN revision: 32161
I wrote the first version thinking on regular, non-pre multiplied
colors, but raster pointed out that all color data is pre-multiplied
inside Evas. I was blaming 16bpp for low quality graphics, but it
turned out that was an error with my usage.
If you experienced grayish colors when using transparency, or white
turning into black while fading out, then these should be fixed now.
Now everything looks better, brighter! :-) Expedite shows no
performance regressions, but I'd like to see more tests on
that. Please report any issue.
SVN revision: 32037
software-16 uses. it works and in some cases gets massive speedups (70%+) but
in a few its slowdowns (30% down) in expedite tests - why, i don't know. it
should be the same or better in all tests. disabled for now - also not
complete. < 32bpp wont' work and not sure rotation works and masks don't work
either.
SVN revision: 31928
By using a single XShmImage we avoid round trips to X and avoid
having kernel to allocate (and zero) memory on every redraw.
This also enable us to issue a single XShmPutImage() with the whole
XShmImage just by using X Region and setting it as clip on Graphics
Context (GC).
On Nokia N800, expedite gains is about 10fps, while my other test
with fewer objects (and thus drawing areas) I could go from 50fps
to 160fps.
Drawback is that we hold XShmImage until evas is resized or destroyed,
we need a new API to flush engine memory so when it is idle for time
we flush this memory, but it is kept alive during animations.
SVN revision: 30390
tuned for best performance on my core2 duo desktop - for now. will check
more. also make the yuv colorspace code be a bit more robust and fix leak in
gl engine with shaders.
SVN revision: 30192
in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3
textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex)
are simply getting values from the Ytex - regardless of what i try. grrr.
what's up with that?
SVN revision: 27495
currently does nothing and i have kept it VEEERY generic it's a pointer to a
native surface which can be just about anything - each engine will probably
define a format of its own you need to use VIA the native surface type.
2. add calls to set/get colorspace - moving this down into the engine level.
so far engines do nothing at all with it - but api is there.
3. clean up gl engine a bit - make it more standard.
SVN revision: 27389