Currently ACCELERATED_2D_CANVAS is enabled by default on most systems (which have CairoGL) but not on Debian (which does not). We've known this was problematic for a while, since it means we have two different sets of distro-dependent bugs, but never decided whether that outweighed the benefits of CarioGL or not. I'm making the call now: it's more important to have the same bugs everywhere. We can turn this on again for other distros when we're ready to turn it on for Debian.
Okay. Sounds reasonable to me.
Created attachment 259947 [details] Patch
Comment on attachment 259947 [details] Patch Clearing flags on attachment: 259947 Committed r188973: <http://trac.webkit.org/changeset/188973>
All reviewed patches have been landed. Closing bug.
The script Tools/Scripts/build-webkit is still enabling this feature by default for the GTK port: $ grep -C1 accelerated2DCanvasSupport Tools/Scripts/webkitperl/FeatureList.pm { option => "accelerated-2d-canvas", desc => "Toggle Accelerated 2D Canvas support", define => "ENABLE_ACCELERATED_2D_CANVAS", default => isGtk(), value => \$accelerated2DCanvasSupport }, This means that both the developers and the bots are building and testing with this feature enabled. Should we do anything about that?
It's expected that build-webkit often enables experimental options that are disabled by default for end users. Advantage of having enabled: If we disable it, there will be zero testing of the feature, and it could break. Disadvantage of having enabled: It could make it impossible to reproduce bugs with a development build. But ACCELERATED_2D_CANVAS is a public (non-experimental) option, which argues in favor of it being enabled for developers and tested. Maybe it should be private, though.