feat: Render the exact size the URL advertises - #148
Merged
Merged
Conversation
The helper floors the fitted size into the URL and into the tag's width and height, but the pipeline refit that floored box against the source, so the other axis shrank: a 320x200 image served 246x154 for a tag claiming 247x154. Of the 2055 distinct sizes the helpers generate for that image, 226 rendered smaller than advertised. Split ImageProcessor#resize in two. resize keeps its fit-inside-a-box semantics; the new resize_exact forces the size it is given. ProcessedImage#crop_and_resize and Model::Transformations#resize both already computed the exact size, so they now use it. That brings the 226 mismatches to zero. Forcing stretches sizes that don't land on the image's ratio, by a median of 0.73% and at most 6.43%. The browser already performs that stretch today, with a worse resampler, since the tag advertises the forced size either way. The variant lookup key is unchanged, so existing variants keep serving their old one-pixel-short blobs until they are purged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #147, which flagged this path as still losing a pixel. The helper floors the fitted size into the URL and into the tag's
width/height, but the pipeline refit that floored box against the source, so the other axis shrank — a 320x200 image served 246x154 for a tag claiming 247x154, and 226 of the 2055 distinct sizes the helpers generate for that image rendered smaller than advertised.ImageProcessor#resizeis split in two:resizekeeps its fit-inside-a-box semantics, and the newresize_exactforces the size it is given, whichProcessedImage#crop_and_resizeandModel::Transformations#resizenow use since both already computed the exact size. That brings the mismatches to zero, at the cost of stretching off-ratio sizes by a median of 0.73% and at most 6.43% — a stretch the browser already performs today with a worse resampler, since the tag advertises the forced size either way.The variant lookup key is unchanged, so existing variants keep serving their old one-pixel-short blobs until they are purged.