When text is rendered into a GraphicsLayer when accelerated compositing is enabled, then it is rendered with no font smoothing (aka LCD antialiasing), because it is not being rendered directly to the screen. This can cause "flashing" behavior when elements start or stop compositing (similarly to the way that text changes for opacity now).
Created attachment 27417 [details] Patch, changelog The rationale for turning off font smoothing when painting with a transform is that the appearance of the text will not change when the transformed element pops into a layer if it starts to animate. Also, it gives web authors a back-door way to control font smoothing.
Comment on attachment 27417 [details] Patch, changelog I don't like this API. If they're instance methods, they should be stored as part of the graphics state (which is what I would prefer). If they're not part of the graphics state, then they need to be static methods on GraphicsContext. But I prefer that they just be added to teh graphics state.
<rdar://problem/6976712>
*** Bug 27272 has been marked as a duplicate of this bug. ***
<rdar://problem/7199704>
*** Bug 35188 has been marked as a duplicate of this bug. ***
*** Bug 40505 has been marked as a duplicate of this bug. ***
*** Bug 47352 has been marked as a duplicate of this bug. ***
Any news about this? It's a pretty old bug, and the problem seems quite important to me, as it could be really obvious (I saw this even on Apple website).
FWIW, I'm only seeing this issue when "position:relative;" is specified within a "position:relative;" parent container and animations are happening on the page AND after upgrading to Safari 5. I'm not sure which version of Webkit it first appeared in... Does anybody have a bare-minimum working example to play with? I can come up with something if it will help. For now, I have come across this issue in a corporate site I'm working on and my own personal site as well. http://beta.daz3d.com/ The issue on this site shows up on the Coda style slider links below the fold (Hot Products, Software, Free Products, etc). On hover, the text is rendered properly. The text is also rendered properly in the current tab when a background image set for the anchor tag. http://www.uberfoto.com/index.php/uberfoto/blog/ For this site, the anti-aliasing from the message preview text is removed while the logo animates and is restored when finished. If these instances help, I'm glad but they are also polluted with a lot of other code. I'll start working on a bare-bones example.
The problem is well understood. It's blocked on a technical issue that is outside the scope of WebKit.
And who to complain about this, then? I'd really like to see this problem solved.
Some video examples of the bug. https://bug-47352-attachments.webkit.org/attachment.cgi?id=70092 http://idzr.org/e69k http://idzr.org/8fwa It happens on images as well: http://idzr.org/11n4 Seriously… nobody at Apple is gonna fix this?
Echo of Alberto's sentiments. This needs attention.
We hear you! We have not forgotten.
The constant displayed version (still shows during animations) of this bug only shows for me when FLASH PLAYER 10.1 is installed.
(In reply to comment #16) > The constant displayed version (still shows during animations) of this bug only shows for me when FLASH PLAYER 10.1 is installed. Right. Flash 10.1 uses the Core Animation drawing model, so tickles this bug.
You made some improvements to this on 10.6.5, right? Elements no longer flickr when you hover stuff. I'm still experiencing the font-antialiasing changes, though.
Seems that the font antialiasing changes are now just on the element and not the surrounding ones. At least, now it's more localized and much less annoying.
There are no WebKit changes between Mac OS X 10.6.4 and 10.6.5. However, the 10.6.5 update may have updated the Flash Player plug-in on your system, which may affect which elements are composited and when.
I assume there's no webkit improvements on this, as somebody told me this problem is outside the scope of webkit (I guess it should be some part of the Mac OS X graphics acceleration then). I was having this issue in a lot of more places besides flash sites (using CSS transitions, iframes…). Just take a look to the videos ;)
Created attachment 75545 [details] Patch
Comment on attachment 75545 [details] Patch Dan gave me feedback; I'll revise the patch.
Created attachment 75624 [details] Patch
Attachment 75624 [details] did not build on chromium: Build output: http://queues.webkit.org/results/6777051
Comment on attachment 75624 [details] Patch http://trac.webkit.org/changeset/73379
Build fix landed in http://trac.webkit.org/changeset/73394. Please verify the change.
Two more changes to do here: 1. Make it work on Leopard. 2. Make it possible for style to override the per-layer setting.
See also bug 50732, bug 50733.
It seems this bug should be marked as closed.
*** Bug 54088 has been marked as a duplicate of this bug. ***
*** Bug 65351 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > The problem is well understood. It's blocked on a technical issue that is outside the scope of WebKit. But subpixel antialiasing worked fine around video elements (e.g. in the controls) in Safari 5.0, even though videos were hardware accelerated. I have no understanding of the technical issues here, but doesn't this show part of the problem is within WebKit's scope?
*** Bug 77547 has been marked as a duplicate of this bug. ***
*** Bug 82898 has been marked as a duplicate of this bug. ***
*** Bug 84282 has been marked as a duplicate of this bug. ***
*** Bug 91613 has been marked as a duplicate of this bug. ***
*** Bug 96589 has been marked as a duplicate of this bug. ***
This bug is still causing trouble on http://pepijndevos.nl on Safari and the latest Webkit. Antialiasing changes from sub-pixel to greyscale after executing "canvas.translate(-200, 400);" Firefox on Mac does not suffer this problem, which indicates to the layman that the bug is indeed in Webkit and not the system itself. Clarification to the contrary would be helpful to avoid misunderstanding.
Why is this issue still not fixed after 4 years? IE10 is now making you guys look bad. This is not an issue on any other browser. font aliasing is a BASIC function and you guys still can't get it working? Safari seems to be turning into the new IE6. This issue should take president over any other "unnecessary" features you guys are wasting your time on.
*** Bug 117006 has been marked as a duplicate of this bug. ***
*** Bug 119904 has been marked as a duplicate of this bug. ***
*** Bug 122165 has been marked as a duplicate of this bug. ***
Hi there, I CANNOT THINK THAT THIS BUG IS 4 YEARS OLD. FONT IS THE NUMBER ONE IMPORTANT ELEMENT IN WEB BROWSING. MAC OS BUCK IN 1984 WAS THE BEST OS CONSIDERED FOR FONT AND SCREEN RENDERING. AND NOW THE MOST USED APPLICATION EVERY DAY , SAFARI, HAS THE WORST RENDERING ON THE WEB. THIS IS THE TRUTH GUYS. LEAVE ALL THE OTHER BUGS . THIS IS YOUR CHALLENGE. THIS IS YOUR BUG TO RESOLVE. ANYWAY. WEBKIT HAS REALLY GOOD SPEED AND SCROLLING…. ANDREAS
*** Bug 122075 has been marked as a duplicate of this bug. ***
Might be 4 years old but it just appeared for me with Safari 6.1 on Mac OS 10.8, looks very bad.
I really don't get why this bug hasn't been fixed in years and it's showing up on more sites than before.
*** Bug 82777 has been marked as a duplicate of this bug. ***
*** Bug 134917 has been marked as a duplicate of this bug. ***
Mr. Fraser, back in Oct. 2010, you said the following: "The problem is well understood. It's blocked on a technical issue that is outside the scope of WebKit." It's now July 2014. This bug has been around since January 2009. Despite being "outside the scope of WebKit" the fact remains that "the powers that be" have had sufficient time to resolve this issue by now. Please describe in detail the specific "technical issue" that has "blocked" it from being fixed for the last 5.5 years. (And please consider that CHROME 35, also built upon WebKit, does NOT have this problem.) Thank you.
This bug is still annoying us. I'm usign chrome 38 and setting a transition on a transform:scale effect, disable antialiasing.
Created attachment 273526 [details] Patch
Created attachment 273527 [details] Patch
Comment on attachment 273527 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=273527&action=review > Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:561 > + BEGIN_BLOCK_OBJC_EXCEPTIONS Seems like these should be inside setBackingStoreFormat, not here.
https://trac.webkit.org/r197923
Re-opened since this is blocked by bug 155301
Created attachment 273652 [details] Patch
Comment on attachment 273652 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=273652&action=review > Source/WebKit2/UIProcess/WebProcessPool.h:194 > + void enableSmoothedLayerText(bool); not sure why this isn't setSmoothedLayerTextEnabled but ok.
https://trac.webkit.org/r197981
Disabled in <http://trac.webkit.org/changeset/198145> due to a massive page load time regression.
Reverted r197981 for reason: Caused a massive PLT regression on Mac. Committed r198189: <http://trac.webkit.org/changeset/198189>
Created attachment 281129 [details] Gibberish
Created attachment 281131 [details] Nonsense
Created attachment 295487 [details] Is this the issue? Is the issue being discussed in this thread manifesting in the attached video. In either case, it's fairly ugly.
(In reply to Jack Wellborn from comment #64) > Created attachment 295487 [details] > Is this the issue? > > Is the issue being discussed in this thread manifesting in the attached > video. In either case, it's fairly ugly. Yes, it is. This has been fixed in macOS High Sierra.