[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] SVG support



	Mano writes:

> Hi again
> Again - about the SVG support in E(FL).
> As I'm not a hacker, I'd like you to explain me if it is possible
> to combine somehow edje/svg, or to use SVG icons in E17 (not to
> convert SVG to bitmap, to use plain, normal SVG files).
> I'm writing this because I was reading one discussion about SVG
> support in Apple's OS X and that they will support 300+ px icons,
> which, as you can imagine is very nice...
> You know that when I commit an icon it's size is scaled down/up
> depending on the font size (or something esle) by Evas. If it is
> a vector grapchic (SVG) not a bitmap we wont lose so much quality.
> And so, I could draw my SVG icons,  and then they will be able to
> be scaled down/up with more quality- even, when we have icons on
> the desktop support we may have very nice 300x300 icons there.
> Hopefully you understood what I meant. And hopefully such SVG
> support is technically possible
> 
> -Mano

	Good questions.. This is an area that could use some
clarifying - maybe raster and rephorm can comment a bit further
on the use of svg docs with edje, and edje theming in general.

	Here are some points to keep in mind as far as evas goes:

 *  Evas can 'load' svg document files (via the librsvg loader).
 *  You can set the size at which to have the doc rendered when
it's loaded.
 *  Once it's loaded, it becomes just another pixel-image for
any further scaling -- scaling it up will get 'fuzzy', scaling
it down will probably be very close to rendering the doc at
that smaller size.
	We could change this behavior for svg docs and have the
scaling done by re-rendering the svg doc each time... But this
is questionable -- at this point in time, rendering svg docs
(by librsvg/cairo) is generally so SLOW that it's practically
useless from a real-time-use point of view.

	Note that thanks to the hard work by raster and onefang,
e17 can already use svg icons -- they are currently loaded at
size 64x64, but there has been talk of allowing this size to be
set as an option. If one were to load them at say 128x128, then
scaling them down from there would likely give just as good
quality as rendering them at such smaller sizes, but would be
a LOT faster.. but it uses more memory.

	Now, here's something to keep in mind as far as edje goes:

	Edje defines its 'themes' via .edc files which are then
converted to .edj files, which is what the edje lib actually loads.
The .edc files refer to certain image files which are normally
png or jpg files, and up to recently, had to be 'inlined' into
the edj file. This allowed for one file (the edj) that contained
all the theme data, which is 'good'.. but like everything, it has
some 'bad' aspects as well.

	Thanks to the hard work by rephorm and raster, it's now
possible for the edc format to refer to 'external' images which
are not inlined in the resulting edj file, but are instead loaded
from their original disk files by edje (via evas).
	With this, it's now possible to define themes which use
such external image files, and these can be any file format which
evas can load -- in particular svg. So, you can actually use svg
files directly with edje (but, as far as I can tell, there's no
way to have the .edc file specify the size at which to load a
referenced image).

	At this point, I think that only e17 uses this.. in the
bg-image-import.


   jose.