Nathan wrote:
1. Split thumbnail generation into pluggable processes. If we can
specify external commands for generating thumbnails, we reduce the
amount of code necessary to support new formats. This also gives us
robustness when a dependency mis-behaves and crashes the thumbnailing
I wrote:
For jpgs you don't have to worry about it since we only
deal with rgb images then, hence there's no difference (and no
premul or un-premul takes place). It does matter for pngs with
alpha though, and then it's fastest to deal with pngs embedded
in eet. But I think the
On Tuesday 04 December 2007, Vincent Torri wrote:
On Tue, 4 Dec 2007, Mike Frysinger wrote:
On Monday 03 December 2007, Vincent Torri wrote:
On Sun, 2 Dec 2007, Mike Frysinger wrote:
On Saturday 01 December 2007, Vincent Torri wrote:
I have added a document in the Wiki that details how to
Build log for Enlightenment DR 0.17 on 2007-12-04 10:19:54 -0800
Build logs are available at http://download.enlightenment.org/tests/logs
Packages that failed to build:
edvi http://download.enlightenment.org/tests/logs/edvi.log
engage http://download.enlightenment.org/tests/logs/engage.log
epdf
On 12/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I don't think there's a need to require that 'thumbnailing'
must involve a specific means for storing some standard image format
somewhere.. one may not want or need to store anything really. There's
really very little difference
