Potential additions to the proposed TextCluster API

[AndresRPerez12]

What is the issue with the HTML Standard?

The possibility to create and render TextCluster objects has been discussed in this issue, and the spec PR is currently being reviewed.

After some discussions around potential use cases for these new capabilities, a couple of interesting points came up around how to make efficient use of the new API and what would be needed to improve its usefulness:

• Adding some kind of unique id or hash to each TextCluster, indicating that the underlying glyph (or glyphs) are the same. This would enable the creation of an atlas to reuse the clusters as textures.
• Exposing bidi level information for each cluster.

We wanted to see what opinions people here have on adding these as read-only attributes to the TextCluster interface. Were not sure what would be the best way to spec a unique id like that, as it doesn't really need to be consistent across platforms, it just has to be unique within each user agent. I tried to look around in the spec for other examples of hashing or generating unique ids but I wasn't able to find a reference.

cc: @whatwg/canvas

[fserb]

Just to clarify. The use case is: how can the developer know that a particular TextCluster matches (rendering-wise) another TextCluster, for the purposes of caching (either calculations or a rendered version of the cluster, for example).

This would be impossible with the current API, as one would need to use the font, the text and the character interval as key hashes, i.e., you could only cache a TextCluster for the same position and the same word. Ideally, users should be able to know "this TextCluster will render identically to this other TextCluster - of the same or another word" and ideally they could do this in a way that can be extended to Maps.

It's not very clear from the use cases we collected if matching those across font-size matters. I'd assume no and assume that we want to match TextClusters if they are the same "resolved font" (with size) and list of glyphs. As Andres mentioned, one way to do this would be to expose a local id (or hash) that is unique for resolved-fonts(font + size):glyph list.

But other ideas would be appreciated too.

[annevk]

I wonder if a more natural API would be some kind of matches() or equals() method.

[AndresRPerez12]

I wonder if a more natural API would be some kind of matches() or equals() method.

In the scenario of building a cache, I think this would require going over all existing clusters that match the substring. I feel it would still be preferable to expose some value that can directly be used as a map key for efficiency.

But I do feel a methods like matches() or equals() can be useful too.

[fserb]

@annevk would something like this work for Maps or Sets?

[domenic]

Sadly no; it is not current possible to customize the equality test used by Maps and Sets. (And relevant discussions in TC39 seem stalled.)

Another possibility would be to always return the same TextCluster object, basically making the user agent do memoization to hide the hash key. This would be somewhat unusual, but doesn't seem impossible? Have a map<hash_key, weak_ptr<TextCluster>> internally, and before returning a new TextCluster, compute the hash key and look it up in the map. If an entry exists, then return that TextCluster instead of creating a new one.

Is that feasible in real-world implementations?

I guess maybe it would require making TextClusters immutable, whereas right now they have mutable x and y properties.