>>> I wonder if it's not better to make their thumbnailer suck less (dump >>> jpg thumbnailer, use code from EPEG or Evas) instead of adding all >>> this complexity. >>> >>> And still we cannot select custom thumbnail sizes, so useless for >>> media centers and lots of fancy systems that might choose something >>> different than 2-power numbers like square 128 and 256. >>> >>> >> And this reminds me of the argument Carsten and I had over evas image >> size-load-options, where I felt it useless and confusing to have such >> options >> that only worked sometimes for some formats some sizes.. rather than always >> for all formats and sizes. >> > > because then you'd be stuck with the non "for free" resizing being done in > software. let me give u an example. you have a photo: 3200x2400. you have a > screen 640x480. you have an acceleration chip (let's say gl). > > you can LOAD the jpeg for less cost than a full load of all 3200x2400 (faster) > if you scale ON LOAD. it can load 5 or 10 times faster. BUT the jpeg format > has > limits. you can only get a scale "for free" with 1/2, 1/4 or 1/8 size. you get > good quality because the jpeg is encoded in the frequency domain (DCT) and all > it does is throw out higher frequencies so you get a filtered scaling anyway. > for free. >
I'm aware of this. It doesn't in any way 'force' us to adopt the current state of things. > this means you would choose to load at 800x600 (1/4). this is higher than you > need, but better than 400x300. NOW your graphics accelerator does the rest and > scales to 640x480. you get to use the engine's native scaling mechanisms after > This is a fairly abstract and specialized argument: "you get to use..." has nothing to do with image-size-load options being respected. You can always "get to use..." whatever, and you can always choose to set your size-load-options to be whatever.. > that. if we ALWAYS scaled to the EXACT SIZE requested - we would be forced to > always do it in software (as part of the generic loader) AND we now need to > also add flags as to if you want raw speed (nearest sampling) or filtered > scaling too - so it adds to the api, and hides and optimisation path. as such > very few people use this api anyway as it requires a fairly advanced knowledge > that you can pre-scale or need to scale to a given size always. i kept it > simple and lefts the rest up to the user. > I'm sorry Carsten, but what you're claiming here as a better load-opts pipeline and semantics in order to give potential gains for some cases needs to be put to the test. And just as importantly, we need to make sure that common-use cases aren't being hurt as a consequence. It's a confusing, complex, user-unfriendly semantics for image-size-load-options and really needs major gains across the board to justify it. Give me some real common-use cases and we'll go thru them in detail, for the main engines and various image formats, and see whether gains or losses are coming from this size-load-opts pipeline. I'll start it off here with one common-use case: Given an evas e, we want to create a "thumbnail" image object in e, of size w1xh1, from a given image file which is a png of size w0xh0, where w1 < w0, h1 < h0 but are otherwise arbitrary. We'll look at it for the cases of e being software, xrender, and gl based. We can move to the case of a jpg source next (which has certain interesting possibilities that could be explored), after we go thru this case. ____________________________________________________________ Get a degree and open new doors. Click to find flexible and affordable programs now. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNbXr6Mg8VuPtL5JS6bLLXqKd6lev9NWIJ6Mr748pi0twr6/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
