Carsten wrote:
> > Unless... Oh, oh.. unless we didn't finish off implementing
> > the load-size option for all loaders. I know we did it for the
> > svg loader, and that the jpg loader respects loading scaled-down-
> > by-dyads, but I can't recall if we really did finish off making
> > sure that all loaders respected the load-size option.. need to
> > take a look. If not, then it should be filed as an evas BUG.
>
> see my other mail. load-size is an option. a loader implements it
> ONLY if it can do a scale-down on load "for free". it is a hint,
> not a requirement. you need to load, then check image size and see
> if you need to adjust/scale later yourself. so only the svg loader
> will scale to the size u want - as it can. the others wont' do
> anything. the jpeg loader will chose the nearest scale size it can
> manage (which is 1/2, 1/4 or 1/8th the width/height of the original
> jpeg file - that's all it can do. this it gets for free tho on load.
> in fact load is faster the more u scale down).
Man, we all say some silly things in time, but this has to
be one of the good ones from you. :) It's a 'load option' so it's
fine for this to be 'optionally' implemented in a loader? Wow!
Tell me, given that this is really trivial to add in evas,
and you end up going thru inefficient loops&hoops to get the 'option'
to actually work in a 'non-optional' way, then why not just have
this actually work?
> > I think evas needs to add an image saving 'size' option,
> > maybe best done via the current "flags" for saving, so that you
> > can save an image that alreday exists at some size (for whatever
> > reason), to a file at whatever other size one wants.
>
> not sure we should do that - as above - its possible to do this
> with buffer canvases and objects. it's much more flexible as i can
> ALSO put MULTIPLE objects into the thumb then. i can add watermarks
> and more to them.
Sure, you can do all sorts of things.. but it doesn't mean
that it's always the best way to get something simple done.
Other than new work required to add something like this
via the api, why do you feel that maybe it shouldn't be done?
**************
> > I doubt it worth the pain, because if we go FDO we must remove
> > any attempt to use .edj as thumbnail format, and it's a good
> > alternative if you want to provide movie thumbnail. Going "too
> > generic" may hurt more than help if nobody else use it, and
> > believe me these guys are hard to get using done by others, you
> > know the NIH syndrome...
>
> agreed it will be painful. i don't think we should force edje
> into a thumbnail format - BUT eet is possibly useful there as its
> agnostic when it comes to glib, qt, efl etc.. the gtnome/kde crowd
> as best i know do not have any such "container format" handler to
> pack many data items compactly into a single file with an easy api
> to access it again. so we are not competing.
I can't see why what FDO wants or doesn't want to support
as 'acceptable' formats should stop anyone from doing otherwise.
In fact, I can't understand why any reasonable, OPEN format would
not be acceptable, nor the reason for *requiring* that some particular
format *must* be accepted.. and none others?? None of this sounds
to me like a body whose decisions should be respected - if indeed
that's the way it operates.. it doesn't sound to me like the spirit
of foss to do so.
jose.
_____________________________________________________________
Find the military school that meets your standards. Click now!
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l91uO8BwI8E6hEJHRkt2eScxmPs1zdarLaGSbnXUKoFNHdu/
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
