Bug 113394 – Add support for runtime flags for experimental blending to chromium

• Component: Platform
• Status: RESOLVED WONTFIX

[Rik Cabanier]

Add the option to enable blending CSS features to chromium through chrome://flags/

[Mihai Tica]

Created attachment 195305 [details]
Patch

[Rik Cabanier]

The CSS_COMPOSITING flag enables the parsing of the blend CSS keywords.
By default, those functions are turned off. Only when the flag for experimental features is enabled, will the css keywords be parsed.

[James Robinson]

Comment on attachment 195305 [details]
Patch

This #define appears to control a lot of code in RenderLayer, RenderLayerBacking, etc.  Where is the runtime guard for these features?  It also does things like make StyleRareNonInheritedData bigger

[Eric Seidel (no email)]

I must be searching wrong.  I only see this controlling parsing?
https://code.google.com/p/chromium/codesearch#search/&q=CSS_COMPOSITING&sq=package:chromium&type=cs

[Mihai Tica]

As far as I know, indeed only the parsing bit is currently done for Chromium. I don't think the other changes under this flag impact the chromium port, as they seem WebKit specific.

[Rik Cabanier]

(In reply to comment #4)
> I must be searching wrong.  I only see this controlling parsing?
> https://code.google.com/p/chromium/codesearch#search/&q=CSS_COMPOSITING&sq=package:chromium&type=cs

That is correct. We are still working on getting the actual rendering in.
There are patches in the works.

[Rik Cabanier]

(In reply to comment #3)
> (From update of attachment 195305 [details])
> This #define appears to control a lot of code in RenderLayer, RenderLayerBacking, etc.  Where is the runtime guard for these features?  It also does things like make StyleRareNonInheritedData bigger

When I first added support, I had them all ifdef'ed. Simon Fraser told me to just put defines on the parsing side because he thought it was too messy.
StyleRareNonInheritedData should not be *that* much bigger.

[James Robinson]

(In reply to comment #7)
> (In reply to comment #3)
> > (From update of attachment 195305 [details] [details])
> > This #define appears to control a lot of code in RenderLayer, RenderLayerBacking, etc.  Where is the runtime guard for these features?  It also does things like make StyleRareNonInheritedData bigger
> 
> When I first added support, I had them all ifdef'ed. Simon Fraser told me to just put defines on the parsing side because he thought it was too messy.
> StyleRareNonInheritedData should not be *that* much bigger.

OK, but that doesn't answer my question.  Where are the runtime guards for this functionality?

[Rik Cabanier]

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #3)
> > > (From update of attachment 195305 [details] [details] [details])
> > > This #define appears to control a lot of code in RenderLayer, RenderLayerBacking, etc.  Where is the runtime guard for these features?  It also does things like make StyleRareNonInheritedData bigger
> > 
> > When I first added support, I had them all ifdef'ed. Simon Fraser told me to just put defines on the parsing side because he thought it was too messy.
> > StyleRareNonInheritedData should not be *that* much bigger.
> 
> OK, but that doesn't answer my question.  Where are the runtime guards for this functionality?

ah, I was replying to making StyleRareNonInheritedData bigger.
see https://bugs.webkit.org/show_bug.cgi?id=111818 for the runtime hooks.

[Ryosuke Niwa]

Comment on attachment 195305 [details]
Patch

Clearing the flag.