On Wed, 29 Oct 2008 11:06:45 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> Gustavo wrote: > > > 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. 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 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. > > On Wed, Oct 29, 2008 at 9:55 AM, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > >> in case your have not subscribed to the xcd ML > >> > >> Vincent > >> > >> ---------- Forwarded message ---------- > >> Date: Wed, 29 Oct 2008 12:52:53 +0100 > >> From: Philip Van Hoof <[EMAIL PROTECTED]> > >> To: [EMAIL PROTECTED] > >> Subject: Re: Prototype thumbnailer now has a Epeg plugin > >> > >> On Mon, 2008-10-27 at 13:38 +0100, Philip Van Hoof wrote: > >> > >>> Hi there, > >>> > >>> I implemented a plugin that uses Carsten's Epeg library to create > >>> thumbnails of Jpeg files[3]. > >>> > >> This EPeg support made me conclude that the specialized thumbnailers do > >> need a URI-scheme support registration. But not for tackling the VFS > >> issue. > >> > >> The reason is that you can have a thumbnailer R that doesn't support > >> remote URI schemes, and you can have a thumbnailer K, supporting the > >> same MIME types as R, that does support remote URI schemes. > >> > >> For example the EPeg thumbnailer doesn't support remote URIs, because > >> the library EPeg only works with local paths. The GdkPixbuf based > >> thumbnailer supports both remote and local URIs, as the GdkPixbuf based > >> thumbnailer uses GIO and GInputStream to load the image from. > >> > >> This means that the generic thumbnailer needs to elect the GdkPixbuf > >> based one in case of a URI-scheme that is not file and a MIME type that > >> is image/jpeg. > >> > >> However > >> > >> In case the URI-scheme is "file" and the MIME typs is "image/jpeg", it > >> instead needs to elect the EPeg based thumbnailer. > >> > >> At the "Registering your thumbnailer" section [1] I added support for > >> this use-case to the specification. > >> > >> $XDG_DATA_DIRS/thumbnailers/com.rasterman.Thumbnailer.service: > >> > >> [D-BUS Thumbnailer] > >> Name=com.rasterman.Thumbnailer > >> MimeTypes=image/jpeg > >> Comment=The great EPeg thumbnailer > >> UriSchemes=file > >> > >> $XDG_DATA_DIRS/thumbnailers/org.gnome.Thumbnailer.service: > >> > >> [D-BUS Thumbnailer] > >> Name=org.gnome.Thumbnailer > >> MimeTypes=image/jpeg;image/png;... > >> Comment=The also great GNOME thumbnailer, but less fast than EPeg > >> UriSchemes=file;sftp;ftp;http;smb;nfs;dav > >> > >> To make sure that the EPeg one is elected for local files that are JPegs > >> you either make sure com.rasterman.Thumbnailer.service's mtime is more > >> recent than org.gnome.Thumbnailer.service and/or you write an overrides: > >> > >> $XDG_DATA_DIRS/thumbnailers/overrides: > >> > >> [file-image/jpeg] > >> Name=com.rasterman.Thumbnailer > >> > >> ps. The prototype [2] is adapted for this. > >> > >> > >> [1] > >> http://live.gnome.org/ThumbnailerSpec#head-2a0cd233f583dcde553c0a8b5150fa737f73cdce > >> [2] https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-thumbnail/ > >> > >> hf > >> > >> -- > >> Philip Van Hoof, freelance software developer > >> home: me at pvanhoof dot be > >> gnome: pvanhoof at gnome dot org > >> http://pvanhoof.be/blog > >> http://codeminded.be > >> > >> _______________________________________________ > >> xdg mailing list > >> [EMAIL PROTECTED] > >> http://lists.freedesktop.org/mailman/listinfo/xdg > >> > >> ------------------------------------------------------------------------- > >> 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 > >> > >> > > > > > > > > > > ____________________________________________________________ > Click to receive credit card help and get out of debt fast. > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m2DVIliupxPqMXcSVUO7zUHAynXq9mPlmv8GaYqV53OaIgs/ > > ------------------------------------------------------------------------- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
