[
https://issues.apache.org/jira/browse/FLEX-34769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044889#comment-15044889
]
Harbs commented on FLEX-34769:
------------------------------
I just spent some time on this and here's what seems to be happening:
1. The composer is calling updateAllControllers(). This composes the first 25
lines which takes about 200 ms in a debug swf.
2. ContainerController.scrollToRange() is called. This causes lines 0-6298 to
be composed. Presumably this is by the check in the aforementioned method if
(flowComposer.damageAbsoluteStart <= endPos) in which case, it calls
flowComposer.composeToPosition(endPos);
3. ContainerController.verticalScrollPosition is then set which then triggers
another composition of lines 0-6299.
4. EditManager.applyLeafFormat() then causes another composition of lines
0-6299.
5. This triggers SelectionManager.refreshSelection() which causes
ContainerController.verticalScrollPosition to be set again which triggers a
composition of lines 0-6300.
So, in short, we have five distinct compositions of the text, 4 of them is the
full text and not just the displayed text.
Here's the problems as I think we have them:
1. Based on the test results, it seems that TLF used to only compose the
visible text no matter how much text there is. I don't know how this could have
worked. How could you scroll to a specific place in the text if it's not
composed?
2. The current code is composing the full text multiple times even though the
text in not being damaged.
3. Every set of verticalScrollPosition is triggering a full composition even
though nothing changed about the text. (items 3 and 5)
4. applyLeafFormat() is causing composition of text, even before the start
index of the modified text.
I'm going to see if I can run these tests on the old TLF code and see how it
behaves there. Once I have clear before and after behavior, I can come up with
a plan to fix this... Any input welcome!
> TLF Performance issue (applyLeafFormat method)
> ----------------------------------------------
>
> Key: FLEX-34769
> URL: https://issues.apache.org/jira/browse/FLEX-34769
> Project: Apache Flex
> Issue Type: Bug
> Components: TLF
> Affects Versions: Apache Flex 4.10.0, Apache Flex 4.11.0, Apache Flex
> 4.12.0, Apache Flex 4.13.0, Apache Flex 4.14.0
> Environment: OS: Windows 7
> AIR version: 15 and 16
> CPU: Intel i7 2630h
> RAM: 4GB
> Reporter: goratz
> Assignee: Harbs
> Labels: flex, performance, tlf
> Fix For: Apache Flex 4.9.0
>
> Attachments: TLFPerfTest.as, TLF_Bench.fla, textLayout_14.swc,
> textLayout_9.1.swc
>
>
> I have a very strange performance difference between 2 versions of
> TextLayout.swc. The first one is the swc included in Apache Flex 4.14 SDK and
> the second one is included in Apache Flex 4.9.1.
> I have a very large text, more or less 200 DIN-A4 pages in a Textflow. I
> scroll to the end of the document and I underline a word. This is my result
> underling a word in both versions.
> Flex SDK Version Time
> 4.9.1 21 ms (miliseconds). 0,02 Seconds
> 4.14 3.405 ms (miliseconds). 3,4 Seconds
> The time difference happens in this line of code:
> EditManager.applyLeafFormat(oFormat);
> Anyone has any idea what's the problem?
> More info:
> https://issues.apache.org/jira/browse/FLEX/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
