Bug 103079 – [EFL][WK2] MiniBrowser rendering should not get blurry when scrolled down with different scale values

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[WebKit Review Bot]

[EFL][WK2] MiniBrowser rendering gets blurry when scroll down with scale != 1.0
Requested by rafaelbrandao on #webkit.

[Rafael Brandao]

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.

[Kenneth Rohde Christiansen]

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.

[Rafael Brandao]

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.

[Kalyan]

(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.

[Kenneth Rohde Christiansen]

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

[Kenneth Rohde Christiansen]

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

[Rafael Brandao]

(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. :-)

[Kenneth Rohde Christiansen]

Created attachment 176253 [details]
Test case

[Kenneth Rohde Christiansen]

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

[Kenneth Rohde Christiansen]

At 0.90 every 10 steps are fine.

[Kenneth Rohde Christiansen]

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());

[Kenneth Rohde Christiansen]

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

[Kenneth Rohde Christiansen]

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.

[Rafael Brandao]

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

[Kenneth Rohde Christiansen]

Created attachment 176449 [details]
Patch

[Kenneth Rohde Christiansen]

Landed in 136000