[
https://issues.apache.org/jira/browse/FLEX-34769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045167#comment-15045167
]
Alex Harui commented on FLEX-34769:
-----------------------------------
I could certainly be wrong, but I thought for many operations you can compose
starting at the nearest prior paragraph boundary and it will "do the right
thing". I think you have to do a full compose to figure out the vertical
scroll position, but after that, for underlining text it shouldn't matter. The
code I mentioned earlier in these comments resets the _startComposePosition to
zero. I would recommend trying to get a better picture of what
_startComposePosition would have been set to if that line of code never reset
it. IMO, that's the key: it was probably non-zero, but some other thing you
needed, maybe for tables, required a full "from-the-beginning" compose.
IMO, it would be fine to add a "usingTables" flag and have folks pay the price
if they need to use tables.
> 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)
