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/c9b8a703cff266363782eee623ff4e…
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/xwi…
(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/