<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Sep 14, 2015, at 4:08 AM, Jon Rimmer <<a href="mailto:jon.rimmer@gmail.com" class="">jon.rimmer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Hi,<br class=""><br class="">As described in this bug:<br class=""><a href="https://bugs.webkit.org/show_bug.cgi?id=23364" class="">https://bugs.webkit.org/show_bug.cgi?id=23364</a> , Webkit's font<br class="">rendering has been broken for over six years.<br class=""><br class="">What is going on with this issue? Despite assurances from Dean Jackson<br class="">that it had not been forgotten, there has been no updates from Webkit<br class="">engineers since 2010. You guys have been making a welcome effort<br class="">recently around better project communication. I should hardly need to<br class="">explain what a terrible impression it gives to promise users that an<br class="">issue has not been forgotten, then seemingly forget about it for half<br class="">a decade! If there has been a decision to leave this broken, should it<br class="">at least not be communicated and explained to users?<br class=""><br class="">As it is, we have a web application that makes heavy use of<br class="">transforms, transitions and animations, and it looks like garbage in<br class="">Safari, and only Safari, due to the constant flickering of rendering.<br class="">I am aware we can set -webkit-font-smoothing to force LCD antialiasing<br class="">everywhere, but that would mean losing subpixel antialiasing in<br class="">non-broken browsers that honour this property, and we have too many<br class="">Chrome users who would balk at such a sudden degradation in rendering<br class="">from what they're used to. I don't want leave the app looking like<br class="">crap in Safari, but right now it feels like I have no choice but to do<br class="">so. It would be nice to know whether there's any hope that Webkit's<br class="">font rendering will eventually be fixed?<br class=""></div></blockquote></div><br class=""><div class="">Just to clarify, this is an OSX-wide problem, and not specific to WebKit.</div><div class="">WebKit is dependent on underlying libraries for text rendering, graphics</div><div class="">and compositing, and this bug is a consequence of rendering text into</div><div class="">transparent textures, when the destination pixel colors are unknown.</div><div class=""><br class=""></div><div class="">Considerable engineering effort was spent earlier this year in trying to come</div><div class="">up with a solution to this problem. Some of this happened in WebKit[1], but</div><div class="">unfortunately we were not able to come up with a solution that worked well</div><div class="">in all cases. It’s still a high priority item for us, but we are very dependent on</div><div class="">other frameworks.</div><div class=""><br class=""></div><div class="">I did make an improvement which should make animations less likely to trigger</div><div class="">changes in text rendering[2]. Does your content still show lots of text flickers</div><div class="">in El Capitan or a recent WebKit nightly?</div><div class=""><br class=""></div><div class="">Simon</div><div class=""><br class=""></div><div class="">[1] <a href="https://bugs.webkit.org/show_bug.cgi?id=143508" class="">https://bugs.webkit.org/show_bug.cgi?id=143508</a></div><div class="">[2] <a href="https://trac.webkit.org/r181515" class="">https://trac.webkit.org/r181515</a></div><div class=""><br class=""></div></body></html>