Bug 105051 - [chromium] Enable LCD AA if text is painted inside opaque region
Summary: [chromium] Enable LCD AA if text is painted inside opaque region
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alok Priyadarshi
URL:
Keywords:
Depends on: 104956
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-14 12:37 PST by Alok Priyadarshi
Modified: 2013-01-07 16:06 PST (History)
8 users (show)

See Also:


Attachments
Patch (18.72 KB, patch)
2012-12-14 12:51 PST, Alok Priyadarshi
jamesr: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alok Priyadarshi 2012-12-14 12:37:43 PST
We already mark layers whether they can use LCD text based on their transform and opacity. Now actually paint LCD text if it lies inside opaque region.
Comment 1 Alok Priyadarshi 2012-12-14 12:51:32 PST
Created attachment 179517 [details]
Patch
Comment 2 Alok Priyadarshi 2012-12-14 12:54:17 PST
Uploading for early feedback. I still need to add unit-test for OpaqueRegionSkia::isOpaqueInRect().

This version of patch always uses NULL rect for text. So it only enables LCD on layers that have an opaque background (including root layer).
Comment 3 Dana Jansens 2012-12-14 12:56:33 PST
Comment on attachment 179517 [details]
Patch

OpaqueRegionSkia changes look good. It would be nice to use/verify isOpaqueInRect() in the PlatformContextSkia tests.
Comment 4 James Robinson 2012-12-14 13:26:06 PST
Comment on attachment 179517 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=179517&action=review

Won't this produce inconsistently rendered text within a layer depending on how the paint rect interacts with the opaque region?

This patch doesn't appear to actually populate the rect at all, so I can't tell where it is going to come from in general.

> Source/WebCore/platform/graphics/skia/PlatformContextSkia.cpp:449
> +bool PlatformContextSkia::adjustPaintFlagsForText(SkPaint* paint, const SkRect* rect) const

I can't find any callers that pass in a non-null rect parameter - where are they?
Comment 5 James Robinson 2012-12-14 13:29:03 PST
(In reply to comment #2)
> Uploading for early feedback. I still need to add unit-test for OpaqueRegionSkia::isOpaqueInRect().
> 
> This version of patch always uses NULL rect for text. So it only enables LCD on layers that have an opaque background (including root layer).

Ah, I see.  So this doesn't actually do rect-region comparisons.

When it does, where do you anticipate the rect being compared to the opaque region will come from?
Comment 6 Alok Priyadarshi 2012-12-14 13:59:46 PST
Comment on attachment 179517 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=179517&action=review

>> Source/WebCore/platform/graphics/skia/PlatformContextSkia.cpp:449
>> +bool PlatformContextSkia::adjustPaintFlagsForText(SkPaint* paint, const SkRect* rect) const
> 
> I can't find any callers that pass in a non-null rect parameter - where are they?

They will come from estimating text bounds using something like this:
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/chromium/FontChromiumWin.cpp#L240

I chose to not compute bounds in this patch because text drawing code scattered in platform-specific files. I will add them for each platform in separate patches. But if you prefer I can get rid of the rect parameter for now. I could just always check device-clip-rect.
Comment 7 Alok Priyadarshi 2012-12-14 14:09:05 PST
(In reply to comment #4)
> (From update of attachment 179517 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=179517&action=review
> 
> Won't this produce inconsistently rendered text within a layer depending on how the paint rect interacts with the opaque region?
> 

Yes this is a possibility. There is no way to un-paint LCD text in immediate mode. We may be able to avoid it with impl-side painting where we can defer the decision until after recording the SkPicture.
Comment 8 Alok Priyadarshi 2013-01-07 16:06:25 PST
I have decided to abandon this patch and move the refactoring changes to two separate patches here:
https://bugs.webkit.org/show_bug.cgi?id=106266
https://bugs.webkit.org/show_bug.cgi?id=106267