I recommend using scale transforms instead of the fonts size, which can only step on integral numbers. It will be smooth if you animate the width/height scales like other elements yet still render sharply.
yes, @jonathan I’m using scale transform on live text, never font size tweening.
To be specific, this strange jittering during scale transform of headline text has re-appeared only in Chrome browser’s latest versions. Desktop Safari and even Firefox reproduce text scale transforms in a pleasantly smooth way.
I can confirm … this recording is on Chrome Version 72.0.3626.121 (Offizieller Build) (64-Bit)
Something interesting to note: In only appears on the GUN VIOLENCE chart. the other font is smooth… might it be that in one case your scaling a group?
I was suspecting the same @MaxZieb mentioned and I ungrouped the two lines of the headline – look at the elements in the main timeline. Having done this, I unfortunately can’t see any changes in Chrome’s weird render bug.
Some versions back Chrome overtrumped Firefox in smoothness of rendering of animated live text. Now Firefox Quantum got rid of its annoying render bug, but Chrome seemingly have caught on that.
I would love to have the possibility of converting text to a png with alfa inside Hype.
Is it only a scale or do you some how influence positional data?
I used scale transform @MaxZieb with default (X50% Y50%) transform origin and opacity change, no placement /position keyframing.
That’s very interesting. This isn’t the normal jitters, it looks like Chrome is re-rendering the text (good to keep it sharp) with slightly different metrics (bad!). Different fonts illustrate the a little better:
You can work around the issue by forcing 3D graphics acceleration on the element. An easy way to do this would be to add a 1 degree Y rotation. If you don’t like that it is subtly different, you can also add CSS that does a transform:rotateY(0deg) !important to the element, but that will really only work with the text that is in the group otherwise you’ll end up rewriting a used transform rule. The side effect is that large scaling will look blurry with this workaround since it will be using bitmap data and not re-rendering the text.
There don’t seem to be other properties or chrome flags that had an effect to improve this. I tried doing some out-of-Hype isolation to get a better grasp on it and file a bug, but ran into some reproducibility problems. I’ll work on it more later… I suspect this probably isn’t too noticeable on most faster animations.
1 Like
Thank you @jonathan for a thorough investigation on this.
Sometimes the best workaround is to convert headline text to bitmap PNGs, as I did with the second headline - no headache with buggy browser-specific rendering!
When there is no explicit need to keep animated headline text editable and no need to keep the file size ‘slim’ for ad servers, I would love to have the possibility to convert text to a png with alfa on the fly inside Hype ( I’ve mentioned that already in Feature Requests Topic.)
2 Likes
Yeah, it is definitely a good feature request… often anyways one small (in file size) png can be much better of a download than having to make an extra fetch for a font and deal with that.
If you ever hit rendering (or other bugs) please let us know as soon as possible – workarounds are great but often we can fix the problem for all users 
.
I can’t agree with you more. The text to png is something I asked @jonathan. I’ve recently had this strange anomaly on window based computers with my recreated slow-mo easing effect as it was all jagged and not smooth but looking at the greensock version showed no problems.
On second thought, I’m wondering if poster image feature would do this now if I hide all layers but just have a text layer? it’ll probably create a jpg that has a background with no alpha support hmm 
@jonathan?
1 Like
Posters capture with a background. You could get a PNG out of it (internally it stores as such) but there’s no way to avoid transparency right now. Part of the problem is that capturing with transparency introduces a whole host of other issues with the current API we are using. There’s a newer API that might have some better possibilities on 10.13+.
2 Likes