New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users

Issue metadata

Status: Duplicate
Merged: issue 229428
Owner: ----
Closed: Dec 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 485650

Sign in to add a comment

border-width: 0.5px is invisible on high dpi devices

Project Member Reported by, Apr 29 2013 Back to list

Issue description

Version: 28
OS: All

What steps will reproduce the problem?

1. Go to

What is the expected output? What do you see instead?

On a 2dppx device:
- the 0.5px border should be displayed using a 1 device pixel wide line,
- the 1px border using a 2 device pixel wide line,
- the 1.5px border using a 3 device pixel wide line,
- the 2px border using a 4 device pixel wide line.
The 1px and 2px borders are fine. But:
- the 0.5px border is actually invisible,
- the 1.5px border actually uses a 2 device pixel wide line.

Further information:

Much of Blink's rendering is now sub-pixel precise [1].

But border widths still get floored, and not only that but they get floored in CSS pixel space. So border-width: 0.5px is invisible, not just on 1x displays, but even on 2x displays like the Chromebook Pixel and high end Android phones!

Levi informs me that this is because we don't want equal CSS width borders to be displayed using different numbers of device pixels (as might happen if we used FractionalLayoutUnits and rounded when rasterizing, if the borders started at different fractional pixel offsets).

But there must be a better solution to this, and it's particularly bad for borders to sometimes be invisible.

FWIW Firefox for Android has a funny behaviour where it normally floors border widths, except for border widths less than 1 CSS pixel where it seems to ceil them (hence 0.1px and 1.9px are both rendered as 2 device pixels wide). See attached screenshots (taken on a 3dppx device, which makes this even more obvious).

70.7 KB View Download
69.2 KB View Download

Comment 1 by, Apr 29 2013

This is a known issue (and I'm pretty sure we already have a bug for tracking it) and comes down to how we support high-dpi and is not limited to borders but rather applies to anything that is pixel snapped.

For this to work properly we need to pixel snap to device pixels instead of to css pixels, in itself this shouldn't be too hard but will require that we introduce the concept of device pixels to the rendering code. 

Comment 2 by, Apr 29 2013

The other option is to do something more like Firefox does, and move pixel snapping logic closer to rasterization. That code knows about device pixels already, but would need to be taught about LayoutUnits and rounding. I think that may be a cleaner solution.

Comment 3 by, Apr 29 2013

Yeah, doesn't matter where we do it as long as that layer is aware of both device pixels and layout units.

Comment 4 by, Apr 29 2013

One difficulty is the ratio of layout to physical pixels depends on the page scale (aka pinch zoom), which we can change and re-raster on the compositor thread at any time.  If we did pixel snapping somewhere in layout or paint code in Blink, it would only be valid for the page scale factor the main thread knew about at the time and not necessarily valid after zooming in/out.

Comment 5 by, Apr 29 2013


Comment 6 by, Apr 29 2013

The screen-shots show antialiased lines.

In those cases (aa), can we remove all floor/ceil/rounding logic from blink, and let the scaling happen naturally at draw time?

Comment 7 by, Apr 29 2013

For borders we need to guarantee that all borders with the same specified width are rendered with the same width, as long as that guarantee is upheld we can remove the rounding logic. This is required by the css specification and is consistent with the implementation in FF and IE.

We also need to ensure that a border specified to be 1px wide is painted with a width of at least one device pixel or a lot of content will break.

Comment 8 by, Jan 9 2015

Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout

Comment 9 by, Mar 16 2015

Is there any progress made on this? Firefox, Safari and IE all seem to handle sub-pixel borders properly.

Comment 10 by, Sep 2 2015

Blockedon: chromium:485650
Status: Available
Mergedinto: 229428
Status: Duplicate
It looks like this was fixed in  bug 229428  and I can see the expected behavior in Canary 49.0.2573.0.

Sign in to add a comment