Match Pixel Ratio Programatically
Overview
DPR
The device pixel ratio (also called CSS Pixel Ratio) is what determines how a device's screen resolution is interpreted by the browser and also by CSS.
This value could also be interpreted as the ratio of pixel sizes: the size of one CSS pixel to the size of one physical pixel. In simpler terms, this tells the browser how many of the screen's actual pixels should be used to draw a single CSS pixel.
DPR is useful when dealing with the difference between rendering on a standard display versus a HiDPI or Retina display, which use more screen pixels to draw the same objects, resulting in a sharper image.
History
Most of Apple’s devices support a Device Pixel Ratio (DPR) of 2.0 (double physical resolution compared to logical resolution), including iPhone, iPad and Macbook Pro laptops. Android smartphones and tablets followed this trend, but there is a large variety of Android devices with different Device Pixel Ratios. For example, Samsung Galaxy S III has a DPR of 2.0, while the Samsung Galaxy S4 and LG G2 have a DPR of 3.0 (triple physical resolution). Some Android devices have non-round DPR values as well: 1.3, 1.5 and even 0.75.
www.rapha.cc is accessed by many users with HiDPI devices, or laptops with DPR higher than 1.0, so we should deliver high-resolution images to match the high visual quality our users expect. However, higher resolution images weigh more bytes and take more time to deliver, so we should avoid delivering double resolution images to standard devices of DPR 1.0. If we want to deliver different image resolutions to each type of device, we first need to create multiple versions of an image for each supported DPR, then detect the DPR of the user’s current device, and deliver the correct image version.
Creating and dynamically serving images with multiple resolutions, coupled with dynamic DPR detection for correct responsive delivery, can be quite challenging. Cloudinary introduced Retina and HiDPI support with dynamic DPR detection and on-the-fly DPR-specific image delivery.
Aim
The aim of this spike is to evaluate how suitable it is to use the javascript sdk to deliver images and what visual degradation we can expect from implementing it. The main use of the SDKs is to provide the browser with DPR images.
SDKS
On mainline we had the opportunity of testing both the jquery and js SDKs.
jQuery
Pros
- Easier implementation for creating picture tags
Cons
- It doesnt follow our coding patterns
- Uses lots of jQuery packages to achieve something relatively simple
JS
Pros
- Has a much more comprehensive converage of image and video transformations
- Greater functionality over jQuery SDK
- Overlays
- Fade in/out
- Transcode from/to
- Video codecs
- Gravity
- Has framework specific libaries and plugins.
@cloudinary/reactor@cloudinary/ng
Decision
Both SDKs have success in delivering DPR images. However they come at the cost of having to write JS for all of our components on mainline to achieve this. Whilst this is a nice to have, the general feeling is that we won't get a long term benefit from performing this piece of work as we are migrating the front end.
The biggest takeaway from this piece of work is the use of picture elements over images with srcsets. They give us greater flexibility when it comes to serving different images at different sizes. An example can be found below:
