766991 - Rendering in Fennec depends on scroll position

Status: NEW

(Core :: Layout, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

On this page: http://people.mozilla.com/~jmuizelaar/ on a Nexus S in landscape mode the thickness of the underline on some words seems to depend on scroll position.

i.e. zooming in and then back out at different scroll position produces a different rendering of the underline.

This may be related to bug 763838

Comment 1

[Jeff Muizelaar [:jrmuizel]]

This also happens on this page http://www.craftymind.com/guimark3/ where the lines of table appear and disappear depending on the scroll position.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

I talked with roc about this and it sounds like this won't be easy to fix.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

So it appears the only reasonable solution to this is to make sure that any rounding to layer pixels always happens the same way and that the scroll translation always happens in layer pixels.

It looks like webkit handles this by always drawing RenderObjects at the same points and using the translation of the GraphicsContext CTM to adjust for the scroll position.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> It looks like webkit handles this by always drawing RenderObjects at the
> same points and using the translation of the GraphicsContext CTM to adjust
> for the scroll position.

That alone isn't enough, though. After scaling and translating, you could still end up with different subpixel offsets in device space and hence different snapping behavior depending on what the translation is.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #4)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> > It looks like webkit handles this by always drawing RenderObjects at the
> > same points and using the translation of the GraphicsContext CTM to adjust
> > for the scroll position.
> 
> That alone isn't enough, though. After scaling and translating, you could
> still end up with different subpixel offsets in device space and hence
> different snapping behavior depending on what the translation is.

The final translation is always an integer number of pixels so the snapping behaviour will always be the same.