In-Portal Issue Tracker - In-Portal CMS
Viewing Issue Advanced Details
1351 [In-Portal CMS] Front End feature request N/A 2012-07-10 14:03 2012-10-15 05:05
resolved 5.1.0  
none 5.3.0-B1
Adds image pre-resize ability to speed up page loading
0001351: Pre-resize image to speed up page loading
It's obvious, that users upload images in a higher resolution, then actually is needed on a website and they needs to be resized.

Right now to speed up uploading process In-Portal don't resize image right after uploading, but only at time, when it's displayed in a different resolution on a website.
This seems to be very good solution when:

* small amount of users tries to view a page with image thumbnails displayed;
* images were originally uploaded in low resolution (smaller then 1MB on size).

But in case when a lot of users tries to see page with resized images at a same time and original images are ~4MB+ in size, then it will take a lot of memory and will attempt to resize same image multiple times.

In-Portal don't pre-resize images in background, because it can't guess what image dimensions would be requested in actual theme, user set's as primary.

But I have an idea, how to overcome that:

Create new column in Theme table, called ImageResizeRules, where per-path image resize rules will be written in following format:

* /system/path/one/:format1
* /system/path/two/:format2

Usually each line would look something like this:


Actual data to place in ImageResizeRules field of the theme database table will be retrieved from <image_resize_rules> node in /_install/theme.xml file of individual theme.

Then CRON script would scan all rules from each theme and pre-resize images according to them.

Even more, if we would consider using Message Queuing servers, like ZeroMQ, then we could schedule resize jobs right after image was uploaded.
Also need to create "Settings" field (textarea) in each Agents/Scheduled Task. In context of this discussion this field can be used for specification of image resize settings described in original post.
patch pre_resize_images_core.patch (17,038) 2012-10-15 05:02
patch pre_resize_images_themes.patch (3,193) 2012-10-15 05:02
Issue History
2012-10-15 05:05 alex Changeset attached 5.3.x r15574
2012-10-15 05:05 alex Note Added: 0005224
2012-10-15 05:05 alex Status needs testing => resolved
2012-10-15 05:05 alex Fixed in Version => 5.3.0-B1
2012-10-15 05:05 alex Resolution open => fixed
2012-10-15 05:05 alex Assigned To !COMMUNITY => alex
2012-10-15 05:05 alex Changeset attached 1.3.x r15573
2012-10-15 05:04 alex Changeset attached 5.3.x r15572
2012-10-15 05:04 alex Changeset attached 1.3.x r15571
2012-10-15 05:03 alex Assigned To => !COMMUNITY
2012-10-15 05:03 alex Developer => alex
2012-10-15 05:03 alex Status active => needs testing
2012-10-15 05:03 alex Note Added: 0005223
2012-10-15 05:02 alex File Added: pre_resize_images_themes.patch
2012-10-15 05:02 alex File Added: pre_resize_images_core.patch
2012-10-15 05:00 alex Target Version 5.2.1 => 5.3.0
2012-10-12 10:11 alex Note Added: 0005222
2012-10-12 07:46 alex Note Added: 0005221
2012-07-25 05:39 alex Target Version 5.2.0 => 5.2.1
2012-07-10 14:03 alex New Issue
2012-07-10 14:03 alex Reference =>
2012-07-10 14:03 alex Change Log Message => Adds image pre-resize ability to speed up page loading
2012-07-10 14:03 alex Estimate Points => 1

2012-10-12 07:46   
Problems found during implementation:
1. because of "storage_engine" option usage in field declaration in unit config actual images to resize could be distributed across different sub-folders and only knowing exact field declaration can help finding them

2. because of same problem only image filename stored in database can be used to do all of above

Solution to both problems is obvious:
1. specify unit config & field instead of just path on disk (e.g. 'unit-config-prefix:FieldName:<resize_options>') instead of originally proposed '/path/on/disk:<resize_options>' format.

2. get values from given field in database table specified in unit config and for each discovered image filename do proposed resize operation.

Pros: unit can change location of actual image store and this won't break anything.
Cons: original specs changed on the go.
2012-10-12 10:11   
While I was updated theme.xml files in theme I realized, that following rule "l-img:ThumbPath:resize:450x" will:

1. resize images event not related to In-Link, since all modules share same Images table
2. contains system setting value (450), which must not be hardcoded
3. resize in-link module images by in-news module image sizes
2012-10-15 05:03   
Based on all above it's pretty hard to use this system to pre-resize category item images without big overhead. That's why we haven't filled in any resize rules but only implemented plain system which in future can be used by developers.
2012-10-15 05:05   
Fix committed to 5.3.x branch. Commit Message:

Fixes 0001351: Pre-resize image to speed up page loading