On Jan 19, 2008 3:40 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > > 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
>
>         Yes, because that's exactly what we did (for the one and only
> loader that respects that, the svg one), except I believe it was 90 dpi
> not 75 that we used.
>         I can understand some 'option' so particular to a format that
> it had absolutely no relevance to other formats.. eg. a format might
> support various kinds of de-compressions, speed vs quality kinds of
> things or whatnot.. but that's just not what's being adressed here.
> We're talking about, essentially, about image sizes - likely the most
> common attribute you can think of for "images".

I'll agree here with Jose. We should have a way to have the image in
the correct size and maybe choose between the smooth/sampled scaler.
For embedded systems, this can help a lot.
    Use Cases:
      1 - thumbnail view: you open huge JPEG and PNG files. JPEG will
be scaled down to a size _near_ the required (for "free"), while PNG
will not be resized at all. When you do a kinetic scrolling you'll
start getting scaled blits where you shouldn't   :-(    [yes, this can
be worked around with thumbnails of the exact size]
      2 - fullscreen views: also open huge images and do
fade-in/fade-out between then. Right now you get alpha blend WITH
scale, since with our device N8xx we can do at most 12fps fullscreen
alpha blending (expedite test), everything we could avoid would help
here.
     3 - fullscreen views: like the other, but imagine a transition
with scale. We could have the image scaled to largest (screen) size
using smooth algorithm and then do the transition using the sampled.

Is there any internal call to do these scaled blits or just those of
evas_common? If so, those more used to it: there is any way to use
these evas_common functions to do this convertion?

-- 
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: [EMAIL PROTECTED]
   MSN: [EMAIL PROTECTED]
  ICQ#: 17249123
 Skype: gsbarbieri
Mobile: +55 (81) 9927 0010

-------------------------------------------------------------------------
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

Reply via email to