ext Ross Burton <[email protected]> writes: >> The performance motivated deviations from the spec are: >> >> - Using JPEG instead of PNG for the thumbnail image format. JPEG is >> usually smaller and we have better optimized code for loading and >> saving it. Generating both PNG and JPEG would be spec compliant but >> very wasteful. > > Another option is to change the spec to say that you can generate JPEG > or PNG I guess.
Yes. This will just work for applications that can generate their own thumbnails. If app-1 wants a PNG thumbnail but doesn't find it, it will generate it. App-2 can do the same for JPEG, and although we waste resources by generating and storing the same thubmnail twice, things will work. But when an application requests a thumbnail from Tumbler, it either needs to be able to control whether Tumbler creates a PNG or JPEG, or it needs to be able to find either the PNG or JPEG, depending on what Tumbler has decided to generate. (And it needs to be able to find an existing thumbnail without talking to Tumbler, so it really needs to check for both; Tumbler can't just report what it has generated.) The spec could continue to guarantee that ~/.thumbnails/normal/ and ~/.thumbnails/large contain PNGs, and only non-standard flavors such as ~/.thumbnails/meego-video-grid/ might be JPEG, as defined by that flavor. Applications using Tumbler would have to know that the flavor they are requesting comes as a JPEG >> - The predefined thumbnail sizes are not appropriate for our devices >> and we need to be more flexible. (I think the 0.3 version of the >> spec that I just found also moves in that direction.) > > What spec are you referring to here? Sorry, I had confused myself. Google found me that old spec, and it looked more flexible than the current version and even had a table of content, so it looked more recent to me, somehow. _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
