We use 256 buckets with a rbtree per bucket. The key of rbtree is the hash
on 12bits and each node of the rbtree have a list of string.
Thanks to Gustavo and Vincent for their help.
SVN revision: 36000
add autogen.sh in archive distribution
* configure.ac:
remove useless defines
first support of mingw32msvc compiler
* src/lib/Evil.h:
move some macro definitions
* src/lib/Makefile.am:
add evil_(fcntl/langinfo).(c/h) and install pwd.h
* src/lib/dlfcn/dlfcn.h:
remove useless ifdef
* src/lib/evil.c:
comment all code for now. It will be deleted later
* src/lib/evil_fcntl.c:
* src/lib/evil_fcntl.h:
* src/lib/evil_langinfo.c:
* src/lib/evil_langinfo.h:
move fcntl and langinfo related code to their own files
* src/lib/evil_mman.c:
remove useless inclusion
* src/lib/evil_pwd.c:
pw var is not needed with cegcc
* src/lib/evil_stdlib.c:
fix bugs, formatting
* src/lib/evil_unistd.c:
add missing declarations and fix header files
* src/lib/evil_unistd.h:
move pid_t typedef to Evil.h
* src/lib/evil_util.c:
additional include and fix a bug in output
* src/lib/pwd.h:
use EAPI from Evil.h, define struct passwd when not using cegcc
* src/lib/sys/mman.h:
use EAPI from Evil.h
* win32/common/fnmatch.c:
* win32/common/fnmatch.h:
* win32/common/fnmatch_list_of_states.c:
* win32/vs8/evil.sln:
fix and cleanup with vc++ compilation
Based on patch by Dmitriy Mazovka
SVN revision: 35993
I did test this patch since three month in my apps and in E, and I didn't
notice anything going wrong with it. If you experience strange bug with
matching please report them.
SVN revision: 35945
them from being put in the evas_render_update phase.
I did extensively test this patch since a few month and didn't notice any
bug with it in my apps, nor in E. But please report anything that goes wrong
for you after this version.
SVN revision: 35944
One can get engine names with ecore_evas_engines_get() and present
them to its users (from --help, for example) and then give that name
to ecore_evas_new(), that accepts the name, geometry and extra options
as a string.
As I don't have all the engines here, I might have missed something
from those, tested here:
- software_x11
- xrender_x11
- opengl_x11
- directfb
- buffer
SVN revision: 35919
Edje is tricky, it's event processing is too weird and Cedric's
changes to make it work are not working as expected. Edje freezes
itself while processing signals, but in mouse down cb it forces
recalculate, which seems was previously ignored, but now they are not.
We should look at how to fix this and then re-apply this patch.
SVN revision: 35908
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 allows e etc. to adapt to massivelyt different dpi screens with
slickness that even svg can't get to... why? you scale just what NEEDS
scaling (text, button sizes, and other limiting elements). other bits like
borders, padding etc. can remain pixel-perfect and thus the look is amazing.
pixel-perfect drawing with scalable adapting.
SVN revision: 35895
Davide Andreoli
Gustavo Sverzut Barbieri
Cedric BAIL
Vincent Torri
Carsten Haitzler
Sebastian Dransfeld