Previous work, rewriting gfx types to support parts of WebKit ported out of it: https://bugs.chromium.org/p/chromium/issues/detail?id=147395
Previous work, adding ScrollOffset: https://bugs.chromium.org/p/chromium/issues/detail?id=414283
We have today..
In blink platform:
- Int{Rect,Size,Point}
- Float{Rect,Size,Point}
- FloatPoint3D
- FloatQuad
In public platform:
- Web{Rect,Size,Point}
- WebFloat{Size,Point,Point3D}
- WebDouble{Size,Point}
In gfx:
- Rect,Size,Point,Vector2d
- {Rect,Size,Point,Vector2d}F
- Point3F
- QuadF
- ScrollOffset
At one point the compositor lived in Source/WebCore/platform/graphics/chromium, and used blink's Int/Float geometry types. When we moved the compositor out, we audited the gfx geometry types and found them to be lacking in functionality and performance. Our initial plan was to reimplement the blink types in //cc as CCMath types, as seen in the initial proposal of this bug.
We had some strong support from piman@ at the time to instead change gfx types to work for us. We managed to convince the owners there to let us make changes to gfx types to provide the functionality, performance, and type-conversion-safety that we needed and had expected from the blink types.
One design decision we made while boiling the ocean, and this diverged us from the blink types, was to stop using Size or Point types to represent 2d vectors. There is some debate on the bug about this, which you may find interesting. I think this captures the reasoning behind the decision.
Because we no longer allowed size+size or point+point, this required non-mechanical changes, making logical decisions about what was a size and what was a vector. Mostly this was not difficult at all, and led to improved readability and typesafety in the code. It also led to our ability to disallow negative Sizes.
There's a long series of behaviour and API fixes that follow on that bug.
Since then, we also converted scrolling offsets away from Vector2d to be a separate ScrollOffset class, since we wanted the ability to use doubles for them. That bug shows the process at which we decided on the representation. There is a TODO about reconciling this with blink, which would be resolved if we switched FloatPoints to ScrollOffsets there as appropriate.
I wanted to give this history to help motivate moving blink to use gfx types. I think that most of the work has already been done here. Layout types appeared in blink since then, so we'd need Layout <-> gfx conversions instead of Layout <-> blinkgeom conversions. If we can achieve that, then the Web geometry types disappear, and we lose a lot of type conversions and extraneous API layers across the graphics stack.
Comment 1 by danakj@chromium.org
, Jun 30 2017