Excelent!!! but what is the first impact for non-developers users?
2011/5/13 Carsten Haitzler <ras...@rasterman.com>
> 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
>
--
Wido
------------------------------------------------------------------------------
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
