work. (in ello) elementary stuff seems... less happy. will work on it! also
havent done the gles bits. just desktop gl (first port of call for
doing/testing). the #ifdefs are ther waiting with fixme's
SVN revision: 43653
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
that dont have runtime compilers using offline tools. binary blobs will need
to be provided in src trees as the shader_type_bin_target.h files
SVN revision: 43004
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
* allow the build of evas without xlib installed (for OpenInkpot guys)
* add big fat warning when at least a module is linked statically (try it !)
more patches will follow now (ecore, e, rage and ewl)
I let pyton and c++ bindings maintainer to do the rename
SVN revision: 41329
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
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
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
Vincent Torri
Carsten Haitzler
Lars Munch
Cedric BAIL
Mike Frysinger
Gustavo Sverzut Barbieri
Tom
Rafael Antognolli
booleanlabel
Jorge Luis Zapata Muga
Sebastian Dransfeld
Samuel F. Baggen
doursse
Peter Wehrfritz
Christopher Michael
moom