Just thought I'd do some announcing for those not keenly following every SVN
commit.
Something that was pending a while back in discussions was the fact that Evas
uses modules to load image formats, BUT some image formats are in one or more
of the following categories:
1. There is a decoder library, but it is buggy and crashes a lot, taking down
apps with it.
2. There is a decoder library but it is GPL, thus forcing all Evas using apps
to become GPL which is not acceptable.
A little while ago i created a "generic loader" for Evas. It's been lurking in
SVN for a little while now in trunk. This is a generic "stdin/shm file/tmp file
loader". What it does is it EXECUTES (and opens a pipe) to an EXECUTABLE that
it just dumbly runs. This executable is "evas_image_loader.EXTENSION" and must
be in your $PATH. if it exists and can be run, evas runs it and reads the
standard output. For a pdf file (X.pdf or X.Pdf or X.PDF) evas tries to run
evas_image_loader.pdf (it turns the extension into lowercase always). For xcf
files it tries to run evas_image_loader.xcf. As xcf files can be gzipped (and
thus be named X.xcf.gz) it will try and run evas_image_loader.xcf.gz and so on.
If none of these extension/type specific loader executables can be run or
exist, then evas tries to run evas_image_loader (with no extension) as a last
resort, hoping that maybe there is a generic "catch all" program (or script
even) that could load something. Note that this isn't necessarily desirable,
but it's a fallback feature I put in just in case someone wants to use it.
This is just the generic "I will run whatever you stick in $PATH" loader. It
doesn't care what is there - just provide it. Thanks to some work by me,
porting over the old Imlib2 xcf loader (and making it also handle gzip xcf's)
and some excellent work by Vincent Torri, in SVN you will see a
evas_generic_loaders "app". This compile currently 2 generic binary executable
loaders. One for XCF (and XCF.GZ files) and one for PDF's. All you need to do
is compile and install this and as long as the binaries are in your $PATH...
evas can now load these file formats. PDF actually even can load selected pages
from a pdf (provide the page number as a key (in a string) to the evas image
file set api like "0" for the 0th (first) path, "3" for the 4th page, "87" for
the 88th page and so on. default is 0 if no key is given. it even supports
pre-scaling and rendering the page at a requested DPI or scale size if you use
the evas load options. XCF's will merge all visible layers into a single image
with alpha. So this is an announce that the generic loaders are now working and
beginning to get useful. Thanks to Vincent for the PDF work and thanks to CK
for the original XCF loader work for imlib2. Packagers may want to start
packaging this. Yes - it's 0.0.9 (not even 0.1) but it works. i'd want to fill
it out a bit more (support scale-down multiplies like jpeg loader does in pdf
loader, make the shmfile support shared code, add a RAW loader that uses
libraw, and add documentation).
For anyone interested in writing more loaders (eg a RAW one or a PS loader that
uses ghostscript etc.), here's how things work.
First - read the XCF and PDF loaders. very much specifically just main(). the
rest of the code is format specific. Now keep in mind how the generic loader
system works:
1. generic loader opens up a one-way pipe of stdout from the executable to the
generic loader module. That means it is parsing ALL stdout from the loader.
Don't print anything to stdout you don't want to send to the loader module. use
stderr if you have to debug.
2. the generic loader executable is passed the following parameters:
executable /path/to/file [options]
there is ALWAYS a filepath as the first argument and then extra options can
be one or more of:
-key KEYNAME
(load the file given and look for KEYNAME "key" inside the file - useful
for holding a page number for a PDF for example, or a key inside a database or
zip file etc.)
-head
(only load the header of the file and produce the metadata like size, alpha
channel etc. and then print "done" as evas doesn't want the image data itself
yet and this is considered the most expensive part to decode)
-opt-scale-down-by FACTOR
(scale the image DOWN by a factor of FACTOR, 1 == dont scale down, 2 ==
scale down to half width and height, 4 == scale down to 1/4 width and height
and so on - loader may limit scale down to powers of 2 and to a limited range
if it wants, and it shouldn't allow scaling to produce a 0x0 image (limit to 1
pixel in each dimension as a minimum))
-opt-dpi DPI
(when decoding use the given DPI if it is a scalable vector graphic. DPI
is actually the real DPI multiplied by 1000 as an integer, so a DPI of 45.3
will be supplied as 45300, or a DPI of 72.0 is 72000)
-opt-size W H
(decode the image so it will fit WITHIN the WxH region in pixels (scale
down if needed or possible, and optionally can scale up if desired). should
retain aspect ratio. look at the PDF decoder for details on how to do this)
note that the -opt-* options are OPTIONAL for a loader to support. it
probably should only support them *IF* it has an optimised load path (can load
as fast or faster WHILE scaling compared to evas doing post-load scaling
itself).
3. stdout carries metadata for the image like size, alpha channel state, and
how the generic loader module should read the rgba data. every command is some
text with a newline ("\n") at the end of the command. commands that the generic
loader understands (i'll use printf notation):
size %i %i
(declare the image size in pixels with the 2 numbers being width and height)
alpha %i
(declare if image has a relevant alpha channel or not - number being alpha
flag, 1 == alpha on, 0 == alpha off)
tmpfile %s
(mmap the file given by %s (absolute path) that contains all the ARGB pixel
data in evas's native ARGB format row by row from top left to bottom right.
file will be deleted by the loader module when evas is done)
shmfile %s
(declare an shm key to be used by the generic loader and shm_open() that
will be mmaped just like the tmpfile above and deleted by the loader module
when finished).
data
(all stdout after the data command (and its newline char) will be ARGB data
written to stdout just like the ARGB data in the tmpfile or shmfile)
done
(loader is done decoding - useful for when asked to decode the header only
and no actual data)
Anyway - there's some news and info for you. I hope this becomes useful to
people and others want to contribute more external loaders to fit their needs.
some ideas for loaders:
PS (postscript) (use ghostscript libs)
RAW (RAW photos) (use libRAW lib)
MPG/AVI/MOV/MP4/etc. (general movie files) (use gstreamer or libxine or
libvlc but just grab 1 frame from the movie (maybe even have smart searching to
jump to the middle and find a frame that isnt boring).
HTML (html pages) (use webkit to render complex pages to memory as images -
liable to maybe be crash prone, thus better as an executable)
TXT (text files) (even use evas to load and render text files to a memory
buffer and provide it as an image - awesome for thumbnailing)
DOC/PPT/PPT/XLS/etc. (office documents) (somehow harness open/libreoffice or
calligra/koffice to load documents and render to memory much like PDF's).
anyway... there you go. all the above are possible and its trivial to provide
the image data evas needs in stdout and/or tmp and shm files you mmap and it
doesn't impact application licensing or stability. so you can be much more
adventurous.
(does someone want to blog about this?)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
