On Tue, 15 Jan 2008 09:36:13 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > 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! correct. load options include things like DPI settings. do you expect every loader to now scale images based on DPI - the loader doesnt even know what the DPI of most image formats is - will it "fake" one (eg 75dpi) just to make this "work" ? these options are there if the loader can do something easily/for "free" while loading. for some formats like SVG rendering at a DPI is part of loading - or at a size, so it comes for free. for jpeg scaling down by 2, 4 or 8 in each dimension is for "free". if every loader implements this i also need to add controls over the scalign quality (smooth or samples for example). > 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'd be a lot of changes to a lot of loaders and it would not be universal as above - dpi is entirely optional as most formats don't have a dpi of the image. so some things would/could work, some could not. i chose to go the whole "only do it if you can do it directly with the format" option. > > > 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? because it now makes savers more complex, adds in a single feature for what is a single use case and is not more generally useful. the buffer canvases do all of it - there is no need to add a saver scale option imho. it just puts more work into every saver (and loader) that is already generic and shared with a common single api (evas itself). > ************** > > > > 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. a lot of foss is not what u think it would be. there is a lot of political infighting, ego stroking and other things that are not related to being open and free - often open and free decisions make way way for personal ambitions. if we present a format that does not have a native g-whatever or k/qt-whatever implementation it basically will be shunned. if we have a format that is not dependent on our own libs (eg edje depends on evas, ecore and edje so it would suck them into kde/gnome) and is stand-alone it has a better chance as it can be seen as less of an "invasion" from the "nih" lands. but in the end - standards bodies - FOSS ones included, are political minefields. they are a sink of time for email and arguments. i'd rather just avoid them myself, but if someone wants to tackle that beast - please feel free. just remember, be prepared to have to argue really hard to have anything not coming from the big camps (gatekeepers basically of the standards) to have an uphill battle. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
