Text Layout Framework Performance and Scalability

[JTtheGeek]

I am rebuilding an old as2 app that supports huge documents, sometimes in the order of 1000+ pages of text.   It needed to be scrolled and not paginated so I originally figured out how to break everything into discrete lines of text, and implemented the scrolling by having a few empty lines above and below that I would inject the content into while scrolling.  It was a little messy but it scaled extremely well, especially considering this was all in as2 lol.     

    So now I'm back at this app, and hoping to leverage a lot of the great features of the TLF.   So the question is what can I do to handle using the TLF and scrolling with extreme scalability in mind.    The first initial thoughts I have are to construct a master text flow of the entire document, then on the fly pull out particular lines of copy, but this solution already sounds pretty painful.

So what are you guy's thoughts on the best way to implement this?

I know I could use pagination for this, but I REALLY want to avoid it at all costs as this simply won't work in all my cases.

Thanks!

~ JT

[brent_arndorfer]

1000+ pages is going to be tough, but I think it would be possible, in theory.  You're definitely going to want to start looking for ways to break it up into pieces, even if you're not using pagination.  Does this need to support editing?  How important is scrolling performance?

[JTtheGeek]

Thanks for your reply.   Yes the document will remain editable, and performance definitely needs to be pleasing to the end user.   Has anyone done some stress testing of the TLF and figured out where it's upper limits are?

So assuming that performance is not going to scale well for large documents my thinking is as such for this case.

• Upon loading a document generate a complete textflow from it;
• create a array of the textlines
• Create a movieclip to contain the visible text lines, and create a mask to show only a certain portion of that area
• manually control adding/removing the textflow displayobjects from the movieclip placing a line or 2 above or below at a time, and manually repositioning each line while scrolling.

I believe this is similar in concept to the original program, but the editability and use of the text layout framework seems like it is going to complicate some things....   if a textline is edited, wouldn't i have to recompute the entire textflow on every character edit and start over?   That dosen't seem like a workable solution in this case...   

Perhaps document editing mode might be in a paginated mode.

There is the other possibility that I can create the pages, but scroll the pages containers, again removing/add displayobjects to the viewstack as they become visable onscreen.   Not sure how much this is going to help though.  

Sorry for the rambling in this post, trying to voice some ideas and get some feed back on these problems from anyone that might have experience.

So with that, voice back any feedback if you have experience or insights here, otherwise I'll post back my findings as I begin prototyping this section.

[brent_arndorfer]

The container controller class does have some capabilities built in that will attempt to optimize which text lines are being created based on the container size and scroll position.  The biggest drawback with the current implementation of that logic is that scrolling performance is diminished due to the fact that composition and text line creation is constantly being done as the user scrolls.

If you would attempt to build a TextFlow with more than 20-30 pages of text and attempt to create all of the text lines in one synchronous operation, flash player will 'hang' for a few seconds or more, depending on speed of client's machine, while Flash Player creates those lines.  I've been able to overcome that by breaking up the composition into chunks that get composed asynchronously across multiple frames.  Once you get past that issue, then you would start running into memory limitations if you try to maintain that many text lines in memory.  It probably will not be feasible for much over 100 pages of text, regardless of client resource availability.

As far as pagination, splitting your long text flow into a bunch of vertically adjacent containers will usually provide the best performance gains.  You can easily do so without the user noticing -- it can still appear to be one long page.  If you do so for something so large, you'll most likely end up having to forgo the usage of the built-in scrolling capabilities of the container controllers and handle that from outside.

We've been successful at providing decent composition, editing, and scrolling performance up to around 100-125 pages.  We'd like to at least double that, so we're starting to look for better ways to break things up into more manageable pieces.  Currently there is no support for chaining TextFlow's together, which is something that could have potential.  Even if we did come up with a solution to chain text flows for presentation to the user, it would make handling editing/selection between the flows a real nightmare.

When a user edits text in a certain position in the text flow, say half way down, it causes damage to the paragraph in which you are editing.  That paragraph consitutes one TextBlock inside of Flash Player's Text Engine.  As a result, in order to update the screen for the edit, all the text lines for that one paragraph will be regenerated during the next round of composition.  Also, I believe any text lines for any paragraphs below that point are geometry damaged and may need to be repositioned.  The x/y coords for all of those text lines are updated during the composition.  Once that work is done, the updateCompositionShapes method on ContainerController is called for containers with lines that were regenerated or damaged to update the text lines in the display list.  That method is a fairly expensive one, doing a concurrent iteration over the text lines that are currently displayed along with the text lines that need to be displayed for the container.  The lines are compared by reference and added/removed as needed.  The logic works really well until you run it synchronously on a long text flow or on a large number of containers.  Out of the box, TLF does a decent job of preventing updates that aren't necessary, but it's not optimized yet for extremely long flows...

There is a lot of room for discussion and brainstorming here about how to handle very long text flows.  I know that it's something that is on the radar for the TLF team, but I wouldn't expect too many improvements for this in the near future with everything else that's on the plate for v1 release.

Hope this gives you a little more insight,

Brent

[rdermer · Accepted solution]

Hi,

I'd reccomend the following with the current state of things:

1) subdivide the long flow into chapters with each chapter being a separate TextFlow.See the Pagination example here:

http://blogs.adobe.com/tlf/2008/12/actionscript-pagination-exampl.html

You won't have the ability to select across chapters.

2) virtualize your content - Flash objects are expensive - think of ways to make a virtual view onto your document that minimzes the object count.  I'd reccomend a scrollable view that as you page through to new chapters creates TextFlows, containers and TextLine's for only those that are visible.

3) Make at least one ContainerController and Sprite per page.  There's been some recent work that will appear shortly that speeds up the composer quite a bit when appending to the end of a multi container TextFlow.  Logic was added so that the composer can skip directly to the first damaged container. This doesn't solve all the performance issues with long flows but it is a start.  Flex hasn't picked up this change yet but it will be available soon.  Look for TLF build 527 or later.

I've attached a test program and a swf built with the skip to first damaged container logic.  Assuming it posts - compare that with your performance if you build the test program with the current code.

Note: attached .as file as a .txt file - rename it and rebuild it with current textLayout.swc to see the previous performance.  There's still more to do for great performance in all use cases of long flows.

Hope that helps,

Richard

[JTtheGeek]

I appreciate your guys help.  I got sidetracked into working on the excel chart exporting feature for right now, but will report back once I complete prototypes on the performance and scalability with the different outlines you all have helped with.