[Webkit-unassigned] [Bug 76520] [EFL] Bad text rendering since r101343

Fri Jan 27 03:47:14 PST 2012

https://bugs.webkit.org/show_bug.cgi?id=76520

--- Comment #9 from Nikolas Zimmermann <zimmermann at kde.org>  2012-01-27 03:47:14 PST ---
(In reply to comment #8)
> When I remove "+ lroundf(lineGap)" from #67 line, result of gtk layout test is very different from original result. About 5,000 test cases are more failed. Can I remove "+ lroundf(lineGap)" regardless of the GTK layout test result ?
> 
> It seems to me that it is better to do rebaseline the EFL result set for layout test. Because, I think EFL port also wants the DRT result as compatible as possible, compared to Mac, GTK port.

Ok, I've discussed this online with gyuyoung. The idea behind this lroundf(lineGap) was to align Mac/Gtk more - and IIRC mrobinson confirmed that it was an visual improvement as well. The current set of EFL results was generated before the lroundf(..) patch went in - so they naturally need a rebaseline - as EFL uses the same FreeType renderer.

Though I think you should judge based on visual experiences. Generate a baseline with eg. the lroundf() patch in, and then remove the patch, rerun tests, and compare the pixel test results, to see what changed visually. If you decide for the EFL port that the old way looks better, you can always add a #if PLATFORM(EFL) exception to the freetype renderer, which is shared between at least gtk/efl.

Another idea might be to make the EFL DRT fallback to platform/gtk results if they're not available in platform/efl, and make sure to leave the lroundf(lineGap) in - this way results in theory could be shared between EFL/GTK, as text rendering is what makes up the most differences in render tree dumps. You should definitely consider this as well.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.