imlib2 bmp loader, but it was imcomplete compared to the bmp
standards, so i actually ended up reading the file format definitions
on line i could find and using lots of test images... wrote a new one.
you can at least view bmp files now. note - i found 1 bmp file that
claims to have an alpha channel (amask is non-empty) and then proceeds
to provide an image with pixels - all alpha 0. so its transparent when
it shouldnt be. beats me but looks like a broken bmp file to me when
it compes to specs.
SVN revision: 49324
rendering. to turn on:
1.
configure with --enable-async-render
2.
export EVAS_RENDER_MODE=non-blocking
presto. necessitates some api swizzling (thus the expedite. ecore etc. changes)
the kind of results you get on a desktop:
http://www.rasterman.com/files/evas-async-vs-none.html
SVN revision: 49087
Samsung Electronics just allowed me to release the first set of ARM neon
patches under the Evas licence. They are silently helping improve EFL and
this another product of their help.
These patches have been tested on a Cortex A8 and show consistent improvement
across the board. For expedite some tests up to 100% improvements, and
practical real world examples show that rendering limited applications show
similar improvements. For instance in one application from 17fps->30fps or
for another 40->63fps.
The patches are pure neon code (intrinsics tend to generate worse code). To
build under GCC you will need a recent GCC and the following C flags:
-mfloat-abi=softfp -mfpu=neon
I also recommend -O2 and -ffast-math.
If you have any problems please let me know.
SVN revision: 48733
Do this for consistency with other applications, some people just set
.Xdefaults but do not have xrdb to load it to screen. This works with
most of the systems, like Gtk and Qt, but not in Evas, so we get
different font sizes as they calculate based on DPI.
HOWEVER, and this may be a big thing, so RASTERMAN take a look, this
might impose a performance hit on window creation... remember that
every E17 popup/tooltip will hit this process of reading the file (if
exists) and then query X server (round trip).
I'd rather make this a global resource, loaded just once for all
created windows, we can store the mtime to know when it changed and
invalidate the pointer... but as Raster did not keep the
XrmGetDatabase() result as global, I'm not doing it here either.
SVN revision: 48403
files: using the SVN revision instead of the datestamp. Other
methods can still be used, however, by adding (e.g.):
--define "_rel 0.`date +%Y%m%d`"
to the rpmbuild command line.
Other spec files will need similar changes. This is just the first
few.
SVN revision: 48099