flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-34769) TLF Performance issue (applyLeafFormat method)
Date Mon, 07 Dec 2015 13:12:10 GMT

    [ 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)

Mime
View raw message