* 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
for the modules. The order and locations are:
1. ~/.evas/modules/
2. $(EVAS_MODULE_DIR)/evas/modules/
3. dladdr/evas/modules/
4. PREFIX/evas/modules/
SVN revision: 32098
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
Now EVAS_CALLBACK_FREE is emitted after smart object's "del"
implementation, this way bindings/wrappers can observe this event in
order to release its wrappers and be sure that they'll not be used
anymore.
Please check your existing code to see if you don't rely on the old
behavior.
SVN revision: 31800
Returning a pointer (possible 64bits) where an integer (possible
32bits) is expected may truncate the type, returning just one part
that may be full "0", leading to incorrect behavior. This fix checks
against NULL and resulting value is either 0 or 1.
By: Brett Nash (kill-a-1-in-4-billion-crash.patch)
SVN revision: 31698
Due the comparions, the code worked fine, but use the correct type
size so it's cleaner.
By: Brett Nash (compare-whole-pointer.patch)
SVN revision: 31696