experimental/svg/model/SkSVGAttribute.h - Issue 2234153002: [SVGDom] Add more presentation attributes.

Side by Side Diff: experimental/svg/model/SkSVGAttribute.h

Issue 2234153002: [SVGDom] Add more presentation attributes. (Closed) Base URL: https://chromium.googlesource.com/skia.git@master

Patch Set: Win build fix Created 4 years, 4 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
1 /*	1 /*

2 * Copyright 2016 Google Inc.	2 * Copyright 2016 Google Inc.

3 *	3 *

4 * Use of this source code is governed by a BSD-style license that can be	4 * Use of this source code is governed by a BSD-style license that can be

5 * found in the LICENSE file.	5 * found in the LICENSE file.

6 */	6 */

7	7

8 #ifndef SkSVGAttribute_DEFINED	8 #ifndef SkSVGAttribute_DEFINED

9 #define SkSVGAttribute_DEFINED	9 #define SkSVGAttribute_DEFINED

10	10

11 #include "SkSVGTypes.h"	11 #include "SkSVGTypes.h"

12 #include "SkTLazy.h"	12 #include "SkTLazy.h"

13	13

14 class SkSVGRenderContext;	14 class SkSVGRenderContext;

15	15

16 enum class SkSVGAttribute {	16 enum class SkSVGAttribute {

17 kD,	17 kD,

18 kFill,	18 kFill,

	19 kFillOpacity,

19 kHeight,	20 kHeight,

20 kRx,	21 kRx,

21 kRy,	22 kRy,

22 kStroke,	23 kStroke,

	24 kStrokeOpacity,

	25 kStrokeLineCap,

	26 kStrokeLineJoin,

	27 kStrokeWidth,

23 kTransform,	28 kTransform,

24 kViewBox,	29 kViewBox,

25 kWidth,	30 kWidth,

26 kX,	31 kX,

27 kY,	32 kY,

28	33

29 kUnknown,	34 kUnknown,

30 };	35 };

31	36
	robertphillips 2016/08/11 13:38:54 Why go from class to struct ? Why go from class to struct ? f(malita) 2016/08/11 14:03:16 Just to simplify access, since this has been reduc Show quoted text On 2016/08/11 13:38:54, robertphillips wrote: > Why go from class to struct ? Just to simplify access, since this has been reduced to a trivial container (all the logic is now in SkSVGRenderContext/SkSVGPresentationContext). Would you prefer a class with public fields or maybe full encapsulation with getters/setters? (FWIW I'm not happy with the current verbose/boiler-platey presentation attribute definition and handling, and am looking for ways to refactor/simplify).
32 class SkSVGPresentationAttributes {	37 struct SkSVGPresentationAttributes {

33 public:	38 static SkSVGPresentationAttributes MakeInitial();

34 SkSVGPresentationAttributes();

35	39

36 void setFill(const SkSVGColorType&);	40 // TODO: SkTLazy adds an extra ptr per attribute; refactor to reduce overhea d.

37 void setStroke(const SkSVGColorType&);

38	41
	robertphillips 2016/08/11 13:38:54 Since we're now accumulating SkPaint fragments, sh Since we're now accumulating SkPaint fragments, should fFill be fFillColor? f(malita) 2016/08/11 14:03:16 The SkPaints are just a cache, to avoid reconstruc Show quoted text On 2016/08/11 13:38:54, robertphillips wrote: > Since we're now accumulating SkPaint fragments, should fFill be fFillColor? The SkPaints are just a cache, to avoid reconstructing unnecessarily (possibly premature optimization:). But we still need to accumulate/track full SVG paint info - which includes special values like "none" "currentColor" "inherit" and, in the future, paint server refs (for e.g. gradients).
39 void applyTo(SkSVGRenderContext*) const;	42 SkTLazy<SkSVGPaint> fFill;

	43 SkTLazy<SkSVGNumberType> fFillOpacity;

40	44

41 private:	45 SkTLazy<SkSVGPaint> fStroke;

42 // Color only for now.	46 SkTLazy<SkSVGLineCap> fStrokeLineCap;

43 SkSVGColorType fFill;	47 SkTLazy<SkSVGLineJoin> fStrokeLineJoin;

44 SkSVGColorType fStroke;	48 SkTLazy<SkSVGNumberType> fStrokeOpacity;

45	49 SkTLazy<SkSVGLength> fStrokeWidth;

46 unsigned fFillIsSet : 1;

47 unsigned fStrokeIsSet : 1;

48 };	50 };

49	51

50 #endif // SkSVGAttribute_DEFINED	52 #endif // SkSVGAttribute_DEFINED

OLD	NEW

« no previous file with comments | « no previous file | experimental/svg/model/SkSVGAttribute.cpp » ('j') | experimental/svg/model/SkSVGRenderContext.cpp » ('J')