There’s two parts to performance. With Flash TLF, the bottleneck is really in the TLF code. The FTE composition is pretty low level. With JS, everything is going to be high level. It remains to be seen how the performance of the FTE part will be in javascript. Of course, there’s the chance that things can be improved in TLF as well.
Anyway, as far as rendering of text goes, there’s 4 options that I know of: 1. Native DOM 2. DOM manipulation 3. SVG manipulation 4. Canvas manipulation Each approach has pros and cons. 1: For at least 90% of use cases, native DOM should be fine. By native DOM, I mean simple HTML markup inside a div using standard CSS for formatting. Some edge cases might need a bit of javascript for browser differences, but by-and-large, you get good optimized internationalized rendering of text out the box. This is fine for any text which does not need to be pixel perfect and some text reflow is okay. This should include: labels, basic text areas, normal item renderers, etc. AFAIK, standard DOM text falls short in two/three applications. One is text with effects. While it’s possible to apply simple effects to DOM text, you do not have the level that we’re used to in Flesh. To get really fancy, you need Canvas. The second issue is text which must render in a completely predictable way. Text scaling is a no-no, text reflow is a no-no, and lines must always break in exactly the same place. The third quasy-case is text in the context of SVG and Canvas. standard DOM can be very hard to sandwich between such elements. 2: Problem 2 can be solved by breaking text into tiny span elements (on the character or word level) and position these spans using absolute positioning. This approach is used by Google Docs and works pretty well. It has the same problem vis a vis text effects as approach #1. Both approach 1 and 2 require using standard web fonts which can be an advantage or a disadvantage. It’s pretty hard to know if web fonts are available — especially if you are dealing with unknown fonts. 3. Using SVG fonts and breaking characters/words into separate SVG elements has a lot of similarities to approach #2 with the exception of SVG fonts (maybe?) Apple’s Pages app uses this approach 3.5: It’s probably possible to break fonts down into paths and draw the paths using SVG as well. 4: Probably the best illustration of this approach is txtjs[1]. Font loading is an interesting problem and ted solved it in an interesting way... If we could abstract the rendering using these different methods, they could theoretically be “hot-swappable”. [1]http://txtjs.com On Nov 2, 2015, at 6:31 PM, Alex Harui <aha...@adobe.com> wrote: > Renaming the thread to see if we can get more opinions.. > > There is some evidence that “hot” JS code runs better than “hot” AS code. > So one consideration is the coding patterns themselves. That’s why FlexJS > prefers composition over subclassing, so shared code lives in one place so > it can get “hotter”. > > I don’t know what your “must haves” are. It sounds like there isn’t a > “ready-to-go” JS candidate yet. If the opentype project is well-written, > so that whatever GSUB and GPOS is can be swapped out and upgraded or > plugged-in later, then that might be the right starting point. > > TLF as we know is a beast. I dumped the list of Flash classes it uses and > posted it below. It may not be too big a project to emulate most of these > classes or comment out temporarily the sections of code that rely on some > of these classes. For example, faking up the event classes is easy. > Commenting out the use of stage and accessibility shouldn’t break tons of > stuff. So I think it does come down to abstracting out TextLine and the > other FTE classes, and I don’t know how hard that is. > > Another data point is that I still foresee the need for better “mocking” > of HTML in AS. If the FlexJS workflow, where you run your app in SWF form > to get most of the bugs out (because of the verifier and better > integration between debuggers and IDEs) remains the preferred workflow, > folks will eventually have chunks of “rich text” in the form of HTML they > will want to see in the SWF version, and having a reasonable rendering of > HTML will become more important. TextField can so some things, > TextLine/TLF can do more, but it might be important to put together an > HTML rendering library. If I were to somehow find the time, I would also > use a plug-in architecture so that each HTML tag can be incrementally > added over time. It is an interesting problem of “what are the > fundamentals of the rendering engine such that each HTML tag is > independent or loosely-coupled from the engine”. I prototyped something > like this years ago here: > http://blogs.adobe.com/aharui/2008/01/html_and_flex_1.html > > The thing is: once you have AS code that places text widgets, then that > code should give you consistent placement in JS once it is cross-compiled, > assuming you can get consistent text metrics. > > So, I have no idea what recommendations to make yet, just providing more > information and thoughts. > > -Alex > > flash.accessibility:Accessibility > flash.accessibility:AccessibilityImplementation > flash.accessibility:AccessibilityProperties > flash.desktop:Clipboard > flash.desktop:ClipboardFormats > flash.display:BitmapData > flash.display:BlendMode > flash.display:CapsStyle > flash.display:DisplayObject > flash.display:DisplayObjectContainer > flash.display:Graphics > flash.display:GraphicsPathCommand > flash.display:GraphicsPathWinding > flash.display:InteractiveObject > flash.display:Loader > flash.display:LoaderInfo > flash.display:MovieClip > flash.display:Shape > flash.display:Sprite > flash.display:Stage > flash.errors:IllegalOperationError > flash.events:ContextMenuEvent > flash.events:ErrorEvent > flash.events:Event > flash.events:EventDispatcher > flash.events:FocusEvent > flash.events:IEventDispatcher > flash.events:IMEEvent > flash.events:IOErrorEvent > flash.events:KeyboardEvent > flash.events:MouseEvent > flash.events:TextEvent > flash.events:TimerEvent > flash.geom:Matrix > flash.geom:Point > flash.geom:Rectangle > flash.net:URLRequest > flash.net:navigateToURL > flash.system:Capabilities > flash.system:IME > flash.system:Security > flash.system:System > flash.text.engine:BreakOpportunity > flash.text.engine:CFFHinting > flash.text.engine:ContentElement > flash.text.engine:DigitCase > flash.text.engine:DigitWidth > flash.text.engine:EastAsianJustifier > flash.text.engine:ElementFormat > flash.text.engine:FontDescription > flash.text.engine:FontLookup > flash.text.engine:FontMetrics > flash.text.engine:FontPosture > flash.text.engine:FontWeight > flash.text.engine:GraphicElement > flash.text.engine:GroupElement > flash.text.engine:JustificationStyle > flash.text.engine:Kerning > flash.text.engine:LigatureLevel > flash.text.engine:LineJustification > flash.text.engine:RenderingMode > flash.text.engine:SpaceJustifier > flash.text.engine:TabAlignment > flash.text.engine:TabStop > flash.text.engine:TextBaseline > flash.text.engine:TextBlock > flash.text.engine:TextElement > flash.text.engine:TextLine > flash.text.engine:TextLineCreationResult > flash.text.engine:TextLineValidity > flash.text.engine:TextRotation > flash.text.engine:TypographicCase > flash.text.ime:CompositionAttributeRange > flash.text.ime:IIMEClient > flash.ui:ContextMenu > flash.ui:ContextMenuClipboardItems > flash.ui:Keyboard > flash.ui:Mouse > flash.ui:MouseCursor > flash.ui:MouseCursorData > flash.utils:Dictionary > flash.utils:Timer > flash.utils:getDefinitionByName > flash.utils:getQualifiedClassName > > > On 11/1/15, 11:34 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >> I don’t remember the list off-hand, but a lot is related to language >> specific features. There’s also 3 or 4 levels of ligatures. There were >> some features I wished it supported (maybe it was contextual >> alternates?), but the OpenType support in general is not bad. There’s >> definitely missing pieces in Japanese composition, but there’s also a lot >> of support. >> >> I think native browser support is pretty good, and for basic text >> rendering you can probably fall back to default browser support and for >> text in FlexJS components that’s the way to go, but for pixel-perfect >> composition, browser rendering of text is not going to cut it. >> >> There’s been some efforts to do some OpenType rendering using Javascript, >> most notably Bram Stein's work[1] There’s also opentype.js[2]. But, >> everything that I’ve found which was done to date is really basic. Any of >> the more advanced OpenType features are not supported at all. Some GSUB >> support, but not even basic GPOS support, etc. >> >> It’s kind of scary how hard it’s going to be to really do text right in >> the browser. Getting even close to FTE is really hard. And I haven’t a >> clue what performance is going to be like in JS. I would have to guess >> that it’s going to be a sore point… >> >> [1]https://github.com/bramstein/opentype >> [2]https://github.com/nodebox/opentype.js >> >> On Nov 2, 2015, at 3:07 AM, Alex Harui <aha...@adobe.com> wrote: >> >>> >>> >>> On 11/1/15, 10:26 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> Not just RTL. There’s an awful lot of OpenType features that it >>>> supports. >>>> (Of course It would be great to support even more…) ;-) >>> >>> I wasn’t aware of that. What kinds of things and how do the browsers do >>> it? >>> >>> -Alex >>> >> >
