You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have the implementors evaluated the performance implications of this API for the case when the text contents remain the same while the constraints change rapidly? In this case the application would be passing the same array of text runs but pass a new width/height. If caching could provide performance benefits, then the text engine would also have to perform the following extra computation to produce a cache hit:
Make a defensive copy of the previously formatted text.
Fully traverse the newly input and compare to the previous snapshot.
The engine has to do these things because the text is expressed using plain mutable JavaScript objects (arrays, dictionaries). It's not possible to tell if something inside changed without the extra work.
A common use-case is resizing a window, which transitively resizes text inside. While all the strings and styles remain the same the value of width would change on every frame for multiple paragraphs of text in the UI. Some apps support resizing within the app, such as columns and rows of a spreadsheet.
And my comment in reply:
This is a very good use case to consider and to test for. My expectation at this early stage is that this case would be sub-optimal and that no caching/comparing of deltas between iterations of format are maintained.
These were all good reasons to have a retained data model supported by the platform--changes to the data model could trigger invalidation (or not) and make formatting faster. However, we're making the trade-off with this new approach to remove any retained platform data model and rely on JS strings, and as a consequence, this issue is now very much a potential concern.
There may be an opportunity for a new feature here: given an existing retained metrics object, allow it to be "re-calculated" based only on changing the constraints--no changes to style or text content. Since no new input is needed except for the new constraint it seems possible to make a fast adjustment to the existing formatted metrics and output (or in-place update) new metrics.
letwidth=5;letrenderMe=FormattedText.format("some content...",null,{width: width});functionrenderLoop(){if(width<100){canvasCtx.drawFormattedText(renderMe,50,50);width+=5;renderMe=renderMe.reflow({width: width});// New API to take the existing rendered content and re-flow it given new constraintsrequestAnimationFrame(renderLoop);}}requestAnimationFrame(renderLoop);
The text was updated successfully, but these errors were encountered:
From comment raised by @yjbanov in PR #39:
And my comment in reply:
This is a very good use case to consider and to test for. My expectation at this early stage is that this case would be sub-optimal and that no caching/comparing of deltas between iterations of
format
are maintained.These were all good reasons to have a retained data model supported by the platform--changes to the data model could trigger invalidation (or not) and make formatting faster. However, we're making the trade-off with this new approach to remove any retained platform data model and rely on JS strings, and as a consequence, this issue is now very much a potential concern.
There may be an opportunity for a new feature here: given an existing retained metrics object, allow it to be "re-calculated" based only on changing the constraints--no changes to style or text content. Since no new input is needed except for the new constraint it seems possible to make a fast adjustment to the existing formatted metrics and output (or in-place update) new metrics.
The text was updated successfully, but these errors were encountered: