Support 'paint-order' from SVG2.

Source/core/rendering/style/SVGRenderStyle.cpp

 /*
     Copyright (C) 2004, 2005, 2007 Nikolas Zimmermann <zimmermann@kde.org>
                   2004, 2005, 2010 Rob Buis <buis@kde.org>
     Copyright (C) Research In Motion Limited 2010. All rights reserved.
 
     Based on khtml code by:
     Copyright (C) 1999 Antti Koivisto (koivisto@kde.org)
     Copyright (C) 1999-2003 Lars Knoll (knoll@kde.org)
     Copyright (C) 2002-2003 Dirk Mueller (mueller@kde.org)
     Copyright (C) 2002 Apple Computer, Inc.
@@ skipping 214 matching lines @@
 
     if (svg_noninherited_flags.f.bufferedRendering != other->svg_noninherited_flags.f.bufferedRendering)
         return StyleDifferenceRepaint;
 
     if (svg_noninherited_flags.f.maskType != other->svg_noninherited_flags.f.maskType)
         return StyleDifferenceRepaint;
 
     return StyleDifferenceEqual;
 }
 
+EPaintOrder SVGRenderStyle::paintOrder(int index) const
+{
+    ASSERT(index >= 0 && index < 3);
+    EPaintOrder po = paintOrder();
+    switch(index)
+    {
+    case 0:
+        switch(po)
+        {
+        case PO_FILL:
+        case PO_FILL_STROKE:
+        case PO_FILL_MARKERS:
+        case PO_FILL_MARKERS_STROKE:
+        case PO_NORMAL:
+            return PO_FILL;
+        case PO_STROKE:
+        case PO_STROKE_FILL:
+        case PO_STROKE_MARKERS:
+        case PO_STROKE_MARKERS_FILL:
+        case PO_STROKE_FILL_MARKERS:
+            return PO_STROKE;
+        case PO_MARKERS:
+        case PO_MARKERS_FILL:
+        case PO_MARKERS_STROKE:
+        case PO_MARKERS_FILL_STROKE:
+        case PO_MARKERS_STROKE_FILL:
+            return PO_MARKERS;
+        }
+    case 1:
+        switch(po)
+        {
+        case PO_STROKE:
+        case PO_STROKE_FILL:
+        case PO_MARKERS:
+        case PO_MARKERS_FILL:
+        case PO_MARKERS_FILL_STROKE:
+        case PO_STROKE_FILL_MARKERS:
+             return PO_FILL;
+        case PO_FILL:
+        case PO_FILL_STROKE:
+        case PO_MARKERS_STROKE:
+        case PO_MARKERS_STROKE_FILL:
+        case PO_NORMAL:
+            return PO_STROKE;
+        case PO_FILL_MARKERS:
+        case PO_FILL_MARKERS_STROKE:
+        case PO_STROKE_MARKERS:
+        case PO_STROKE_MARKERS_FILL:
+            return PO_MARKERS;
+        }
+    case 2:
+        switch(po)
+        {
+        case PO_STROKE_MARKERS:
+        case PO_STROKE_MARKERS_FILL:
+        case PO_MARKERS_STROKE:
+        case PO_MARKERS_STROKE_FILL:
+            return PO_FILL;
+        case PO_FILL_MARKERS:
+        case PO_FILL_MARKERS_STROKE:
+        case PO_MARKERS:
+        case PO_MARKERS_FILL:
+        case PO_MARKERS_FILL_STROKE:
+            return PO_STROKE;
+        case PO_FILL:
+        case PO_FILL_STROKE:
+        case PO_STROKE:
+        case PO_STROKE_FILL:
+        case PO_STROKE_FILL_MARKERS:
+        case PO_NORMAL:
+            return PO_MARKERS;

[f(malita), 2013/05/03 14:36:25]

Is there a better way to encode these internally?

For example: a base 4 3-digit number, where each digit is 0/NONE, 1/FILL,
2/STROKE, 3/MARKERS. Then we can avoid testing the whole value space and instead
test one digit at a time and shift. And if we assign EPaintOrder values
carefully, we might even be able to cast this number directly to that enum.

[pdr., 2013/05/03 17:58:29]

+1 to Florin's idea.
Using an int here is not easy to understand, especially at the callsites (e.g.,
in RenderSVGShape). We should design this to make the code in RenderSVGShape
easy to understand without having to refer here to see how it works. It would
also be nice to not have to iterate over every permutation.

[Erik Dahlström (inactive), 2013/06/03 15:58:24]

If we can live with normalizing the paintorder here then that becomes possible.
By normalizing I mean computing the finally used value such that it will always
consist of three parts (instead of e.g one, like "fill" or "normal"). That does
mean that it becomes impossible to map an EPaintOrder value back to the exact
CSSValue(s) that generated it. The computed value should be "as specified"
according to the spec, and if I look at what Firefox nightly is doing it does
return something different than what was specified if I call getComputedStyle
and fetch the paint-order value. It would naturally simplify the implementation
to have a normalized representation here, but the question is if it would be
correct. Thoughts?

+        }
+    }
+
+    ASSERT_NOT_REACHED();
+    return PO_FILL;
+}
+
 }
 
 #endif // ENABLE(SVG)