Would be interesting to be moved as documentation on xwiki.org… :) Best place IMO would be to create an extension for the Image Plugin on extensions.xwiki.org and document it.
Thanks -Vincent On Feb 14, 2012, at 7:56 AM, Sergiu Dumitriu wrote: > On 02/12/2012 05:54 PM, Paul Libbrecht wrote: >> >> Hello fellow xwiki users, >> >> we discovered recently the usage of the width parameter when delivering a >> picture from an xwiki document attachment. >> >> Surprisingly this is available in our production server, based on the grumpy >> xwiki 1.5, but has not been used in the UI of Curriki which has, however, >> been made by a team of XWiki SàRL originally. > > Yes, this has been implemented for a very long time. If I remember correctly, > it might have been introduced even before 1.0, or at least very soon after > that. > >> - can someone describe me how this feature is working? > > Basically, whenever an image download request is processed, the ImagePlugin > intercepts it via the downloadAttachment plugin SPI method, and, if there are > width or height request parameter, instead of serving the original > attachment, it will create a new fake attachment holding the resized image. > >> - is the resulting downscaled image cached in file or in ram? > > There's a filesystem cache for resized images, indeed, so that the same file > isn't scaled for each request. Still, when downloading a specific image, it > will be held in memory as any XWikiAttachment object. > >> - has there been a different implementation between the current xwiki (e.g. >> 3.4) and 1.5? > > Yes, kind of. It used to be all in > https://github.com/xwiki/xwiki-platform/blob/c9b8a703cff266363782eee623ff4eb61aad4b45/xwiki-core/src/main/java/com/xpn/xwiki/plugin/image/ImagePlugin.java#L165 > but the image scaling code has been moved out of the plugin, and is now in > https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/plugin/image/DefaultImageProcessor.java > (the call to this component is still in the plugin, though). > > There have been a few changes and improvements between the two versions. > Besides the width and height parameters, now there's support for a "quality" > parameter, a number between 0 and 1 controlling the compression quality for > JPEG files, and a "keepAspectRatio" parameter which means that in case both a > width and a height are specified, the image will be scaled with the same > aspect ratio to fit within the specified width and height. > >> - except for the CPU hogging of computing the downscaled version, is there >> any reason not to use this feature? (e.g. RAM overloading?). > > It should be used as much as possible. The only problems are the extra > storage needed for storing thumbnails, and the extra CPU time needed to > scale, or at least to access the cached file from the disk. > > In recent versions this feature has been used more and more, so most places > where images are used at a different size should already be making use of > this feature. > >> thanks in advance >> >> Paul > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
