576202 - Create / adopt an enumerated-meaning value type in GFX

Status: NEW

(Core :: Graphics, defect)

Description

[Daniel Holbert [:dholbert]]

(See bug 276431 comment 99 for some background, described briefly below)

In bug 276431, we need a way of querying an SVG-backed imgIContainer for its intrinsic size, and we need to allow both components of the size (width & height) to be either pixel-valued or percent-valued.

Quoting bug 276431 comment #99:
> So the simplest solution would be to have imgIContainer::GetIntrinsicSize(),
> which would return an nsIFrame::IntrinsicSize (which, importantly, can contain
> both percent and px values).  But that doesn't work, because imglib doesn't
> know about nsIFrame, so it can't use nsIFrame::IntrinsicSize (or about
> nsStyleCoord, which is what IntrinsicSize uses under the hood for its component
> parts).  So, to get around that, we could create a new "nsStyleCoord-like"
> structure (which would need to support both px & percent-values) and an
> "IntrinsicSize-like" wrapper for it, somewhere in /gfx/.  And we'd use that to
> replace nsIFrame::IntrinsicSize.  But that would result in semi-duplicated
> code, which isn't great either -- we already have a lot of
> px-or-percent-[or-something-else] value types, e.g. nsCSSValue, nsStyleCoord,
> nsStyleAnimation::Value, and probably a few more -- and adding yet another one
> for just this one purpose isn't ideal.
> 
> Ultimately, we should probably refactor one or more of the existing
> "enumerated-meaning" value types to live in GFX and be suitable for this
> purpose -- but for now, the nsIFrame* accessor is something simple that avoids
> all that hassle.

I'm filing this bug on the last paragraph there -- refactoring one or more enumerated-meaning value types (like nsStyleCoord) to live in /gfx/, so that we can use them for an imgIContainer::GetIntrinsicSize() method.