Bug 103079

How to reproduce: 1. Run MiniBrowser on http://uol.com.br (or any other site that forces scale to be different than 1.0) 2. Observe the font rendered with this initial state. 3. Scroll down with mouse wheel once. 4. Now compare the font rendered with the previous state. There are differences.

I can confirm this scrolling with the wheel. I also notice that at specific steps (say every 5 steps on google.com searching for 'hest') the text becomes clear again.

I've found out so far that rendering the debugging lines (when using WEBKIT_SHOW_COMPOSITING_DEBUG_VISUALS=1) does not get blurry, while the repaint counter does (the rectangle and the number on it). Does this ring any bell? I'm still trying to understand how rendering works.

(In reply to comment #3) > I've found out so far that rendering the debugging lines (when using WEBKIT_SHOW_COMPOSITING_DEBUG_VISUALS=1) does not get blurry, while the repaint counter does (the rectangle and the number on it). Does this ring any bell? I'm still trying to understand how rendering works. Difference between two: Debugging lines: Debugging lines being drawn are nothing but quads with a line width and particular color drawn using shaders. In case of repaintcounter: We use an intermediate surface(cairo_image_surface) to draw the contents of repaint counter. The contents of surface are than copied into a texture.

Description is wrong, it works fine with scale 0.5, 0.75, 0.80, and event 0.85, but a scale such as 0.86 triggers it though

With scale 0.86 y pos 0 is sharp and so it y pos 200 and 400 (didn't test 300) - same with scale 0.81. But with scale 0.816327 it is sharp at 0, 120, 240, 360

(In reply to comment #6) > With scale 0.86 y pos 0 is sharp and so it y pos 200 and 400 (didn't test 300) - same with scale 0.81. > > But with scale 0.816327 it is sharp at 0, 120, 240, 360 Hm, *that* is interesting. :-)

Created attachment 176253 [details] Test case

im wrong, changed scroll step to 1. 0.35: 0 looks fine, then 1 (off like 2 pixels), 2 (off like 1 pixel), 3 (perfect), etc. 0.816327: 0 perfect 1 worse 2 worse 3 worse 4 better 5 better 6 perfect ... 11 perfect It looks like the same font is being painted on top with an offset

At 0.90 every 10 steps are fine.

Trick to scroll per 1 pixel, modify Source/WebKit2/Shared/efl/WebEventFactory.cpp 158 deltaX *= 1; //static_cast<float>(Scrollbar::pixelsPerLineStep()); 159 deltaY *= 1; //static_cast<float>(Scrollbar::pixelsPerLineStep());

It should be noted that while scrolling the tiles are not updated, so this is not a font issue AFAIK

This seems to be from the fact that we send wheel events to the web process, it sends back css positions, which doesn't align to device pixels positions. Ie. we are told to move 10 css pixels but move 8.12339 instead with a scale of 0.812339. Instead of storing css scroll position, we should store the page position, as we also want the user to pan page in device units in the near future.

I will need to work on something else right now, Kenneth is almost there on this bug so please take it! :-)

Created attachment 176449 [details] Patch

Landed in 136000