Concerns about metrics lifecycle

[travisleithead]

I have some concerns about the metric lifetime recommendation. It feels non-intuitive to invalidate format() return structure without the user requesting to invalidate it. Can we provide an invalidate() API so that authors can have control on the lifecycle? If this is as must, how about adding an API to check is the object is valid so that author can decide if it can be use instead of try/catch?

@nhelfman

[nhelfman]

I think that ideally the resulting paragraph object will never be invalidated unless not referenced and subject to GC like any other JS object on the heap. Is there an extensive concern for this which this is necessary? Is this object expected to be significantly more expensive than other typically created objects?

[travisleithead]

In the implementation, we believe there's a lot of state needed to service the metrics requests, and that state is not immutable (is my understanding). In order to avoid invalidation of the JS objects, a copy of all the necessary internal state would be needed (so that the JS objects appear to be a static snapshot), and that could get "costly" in terms of memory. The Jury's still out on this, and we will need some actual implementation experience to see if this is, in fact, a problem. Good to track it here, and think about alternative lifecycle models if needed.

[travisleithead]

Given recent changes to the data model for PR https://github.com/WICG/canvas-formatted-text/pull/39, I'm back to recommending "normal" lifecycle models for the results of formatting. There is now no formal relationship that needs to be maintained between the input data and the resulting paragraph, and so the original lifecycle concern may not apply. Closing opportunistically... can re-open if this becomes a problem with implementation experience.