Changes to the Thumbnail Resizing Logic in our Capture Technology

4 posts / 0 new
Last post
puravida's picture
puravida
Jedi Warrior
Offline
Joined: 09/01/2007
Visit puravida's Website

I have just finished rolling out a fairly substantial change to our capture generators (servers) that appears to have cleared up some recent "incorrectly sized thumbnail" issues.

I feel good about the change, but I would like to ask you to alert us to any oddities you might see in regards to size. First, refresh, because there were a LOT of screenshots captured before this fix. If the refreshed screenshot is still "off", then please let us know so that we can confirm and investigate.

Since nobody reported this, we are going to let the "Rolling Refresh" update these screenshots over the next 15-30 days. If anyone is severely impacted by the sizing issue, please open a ticket and ask for all of your requests to be refreshed.

Thank you for being a valued ShrinkTheWeb user!

GEEK-SPEAK
It has been a long time since the system output web page thumbnails at incorrect sizes, but a script we relied on for years recently caused this issue to reappear --basically breaking our previous "fix".

That script was sooo annoying, because it would hang our render engines randomly 1 out of 10 captures and the method they provided to prevent it just would not work. So I am thrilled to have finally gotten rid of that script, even though it required quite a bit of re-coding on my side. It was well worth the effort.

No one reported this, but we noticed that default sized screenshots were a couple of pixels narrower than they should have been. For instance, a 120x90 would sometimes come out as 118x90. In short, the new fix for this required us to end our reliance on a 3rd-party script to hide the scrollbar. I was able to find a more elegant solution, but it required some changes to how our script handles re-sizing (especially for sites that force a width wider than the browser, which creates a thumbnail wider than expected).

So now, the scrollbar is still hidden by the new method, but the sizes output should be extremely accurate. In the past, I would notice an occasional thumbnail might be a few pixels off in some cases (usually when cropping). I have run through a LOT of default sizes, Full-Length, Full-Length cropped, and Custom Sizes tonight in testing these changes. The new code output 100% accurate sizes, even in tough cases like I mentioned where the output was wider than expected.

These changes should yield far more accurately sized captures and also gives us more control when poorly coded web pages cause unexpected issues.

martinrussell
Offline
Joined: 02/22/2011
Visit martinrussell's Website

We might all sometimes take your service for granted and it's a learning experience to read through the "geek speak" to see what's happening behind the scenes.

Thank you.

puravida's picture
puravida
Jedi Warrior
Offline
Joined: 09/01/2007
Visit puravida's Website

Hah. I'm just glad somebody out there occasionally reads my ramblings! lol Smile

Take it easy,

Brandon

puravida's picture
puravida
Jedi Warrior
Offline
Joined: 09/01/2007
Visit puravida's Website

Update: Tonight's all-nighter also included the following update...

There were a number of slightly "off" (short) images in the database that ended up being caused by web pages that were too short to fill up the requested area. As a result, I have added a "padding" offset to the screenshots in order to output the exact size requested, in every case. The padded area will be white.

No end-user code change is required to take advantage of this new behavior. However, prior requests may still be "short" until refreshed. Some users have mentioned this being an issue in the past, because it can throw off a page design when the image is shorter than desired. I did not have any control over the image size output, but as I was working on the image sizing code tonight; I stumbled across a simple way to pad the difference. Had I known it would have been so easy, I would have done it years ago! Smile

At any rate, this change, coupled with the previous change that started off this thread, really locks down image sizes. They should always match the desired output size now. I thoroughly tested dozens of scenarios, but if anyone runs across anything that is "off", please post in the STW forum or open a support ticket.

Ciao!

ShrinkTheWeb® (About STW) is another innovation by Neosys Consulting
Contact Us | PagePix Benefits | Learn More | STW Forums | Our Partners | Privacy Policy | Terms of Use

Announcing Javvy, the best crypto exchange and wallet solution (coming soon!)

©2018 ShrinkTheWeb. All rights reserved. ShrinkTheWeb is a registered trademark of ShrinkTheWeb.