flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: TextFlowLine recycling
Date Sun, 23 Nov 2014 21:54:12 GMT
Phew!

Looks like I fixed this issue. Once I found the problem, the fix was straight-forward... There’s
still some failures with FloatTests, but nothing as bad as what we were getting before.

I’m going to comment on the other FlexUnit discussion about the remaining errors.

On Nov 23, 2014, at 11:38 PM, Harbs <harbs.lists@gmail.com> wrote:

> Duh!
> 
> I’ve actually been working on this for so long, I forgot what I’ve done! :-(
> 
> I just looked through the git logs and I see, that I’m the one that added _curLineStart.
The code used to get the index from the TextBlock, but that is no longer a reliable method
of getting the index, so I added _curLineStart.
> 
> Since it’s my mistake, I can fix this with impunity! Phew! :-p
> 
> No back to our regular programing… ;-)
> 
> On Nov 23, 2014, at 11:22 PM, Harbs <harbs.lists@gmail.com> wrote:
> 
>> Here’s what I *think* is happening:
>> 1) ComposeState.composeNextLine() calls createTextLine() and gets a TextLine.
>> 2) Part of what BaseCompose.createTextLine() does is: _curLineStart += _curLine.textLength.
That increases the index of where the line is supposed to start from. _curLineStart is the
number used to initialize the TextFlowLine and determines its absoluteStart.
>> 3) ComposeState.composeNextLine() then does a check for fitLineToParcel() on line
425.
>> 4) If that fails, _curLine is set to null without adding it to the flowComposer.
>> 5) The loop continues and a new line is created and initialized at _curLineStart
which was increased by the theoretical length of the line that was never actually used so
things get out of whack.
>> 
>> I’m really nervous about fixing this, because I’m not sure why it’s failing
now, but was not failing before.
>> 
>> The above logic makes no sense to me, but it’s not something that I changed. Without
understanding how it’s *supposed* to be working, I run the risk of breaking other areas
by fixing this. I’m obviously missing some nuance in the logic here.
>> 
>> Anyone interested in sticking their noses into this mess?
>> 
>> On Nov 23, 2014, at 11:00 PM, Harbs <harbs.lists@gmail.com> wrote:
>> 
>>> I went through all the ParagraphElements and TextFlowLines. I added it up, and
it’s clear to me that the _curElementOffset and _cur is being upped by 41 which is the length
of the current line before the line is initialized. That seems to be throwing everything out
of whack.
>>> 
>>> Now I just need to figure out where that’s happening…
>>> 
>>> On Nov 23, 2014, at 9:55 PM, Harbs <harbs.lists@gmail.com> wrote:
>>> 
>>>> I’m back on this. I have a simpler case where things are getting out of
sync.
>>>> 
>>>> I have a line where the _curElementOffset is 382, the _curElementStart is
803 (total 1201).
>>>> 
>>>> The total textLength of the textFlow is 1201.
>>>> 
>>>> The _curLineStart is 1185 and the rawTextLength of the TextLine returned
by the TextBlock is 41. This adds up to more than the total length. Interestingly, the length
of the previous line is 41 as well.
>>>> 
>>>> Adding up all the lengths of the TextLines in the TextBlock only comes to
389, but the paragraph (and span) has a length of 398.
>>>> 
>>>> It looks like the whole paragraph and TextBlock is somehow out of whack
>>>> 
>>>> Sorry for the noise, but I’m writing this in the hope that the lightbulb
will come on for either me or someone reading this…
>>>> 
>>>> Harbs
>>>> 
>>>> On Nov 18, 2014, at 12:23 AM, Harbs <harbs.lists@gmail.com> wrote:
>>>> 
>>>>> Right. My question is more related to TextFlowLines than Slugs though.
>>>>> 
>>>>> Let’s say a flowComposer has an array of TextFlowLines and the geometry
of them does not fit in the new composition space. What is supposed to happen to the old TextFlowLines?
I’m having trouble understanding the architecture here.
>>>>> 
>>>>> What I would have done if I was designing the engine would be to recalculate
geometry of the TextFlowLine each time I’m composing it. If the geometry changed, I’d
throw out the old TextLine and ask the textBlock for a new one. Getting new TextLines, I see,
but recalculating the geometry I don’t.
>>>>> 
>>>>> I assume I’m missing something obvious. If someone can help me spot
it, that would be great!
>>>>> 
>>>>> (BTW I just fixed a vertical placement issue with table blocks. I’m
committing it now.)
>>>>> 
>>>>> On Nov 18, 2014, at 12:17 AM, Alex Harui <aharui@adobe.com> wrote:
>>>>> 
>>>>>> I don’t know for sure, I just looked up the Slug class.  It says
it is
>>>>>> created by Parcels to track geometrical line information.
>>>>>> 
>>>>>> Maybe a simpler test case would help you understand the desired behavior?
>>>>>> I would think at some point if the composable areas change, the Parcels
>>>>>> and their Slugs get updated.  It would probably be either at the
beginning
>>>>>> when the composition is given new bounds, or more likely, gradually
as the
>>>>>> composer works its way down through the container and on to the next
>>>>>> container.  If a Parcel and its Slugs (I’m going to start a band
with that
>>>>>> name!) gets moved to a different container, you would think there
would be
>>>>>> some invalidation of that Parcel if any information is cached, or
maybe no
>>>>>> old information is supposed to matter and everything gets recomputed
>>>>>> during composition.
>>>>>> 
>>>>>> If the table work has changed the recalculation of the Slugs because
>>>>>> you’ve deferred it in order to compute table cells, that might
be the
>>>>>> cause.
>>>>>> 
>>>>>> I’m not sure how well the code works for non-rectangular parcels.
>>>>>> 
>>>>>> Good luck,
>>>>>> -Alex
>>>>>> 
>>>>>> On 11/17/14, 3:27 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>>> 
>>>>>>> Just to be a little clearer:
>>>>>>> 
>>>>>>> I’m not sure why this used to work, and now it doesn’t.
>>>>>>> 
>>>>>>> It seems to me that if the parcel changes on a TextFlowLine,
the
>>>>>>> outerTargetWidth could be changed and the TextLine regenerated.
(Then the
>>>>>>> Slug and the outerTargetWidth should match.) The thing is, the
code did
>>>>>>> not used to do that and I’m not sure how/why.
>>>>>>> 
>>>>>>> Another issue with this approach is what happens if we add the
ability to
>>>>>>> have non-rectangular parcels. The the TextFlowLine width should
need to
>>>>>>> be refigured every time it’s composed (which is something that
I don’t
>>>>>>> think is happening currently). Of course there’s no reason
to worry about
>>>>>>> that until we might be adding that support…
>>>>>>> 
>>>>>>> I’m also not entirely sure what the check that’s failing
is supposed to
>>>>>>> be checking for…
>>>>>>> 
>>>>>>> Harbs
>>>>>>> 
>>>>>>> On Nov 17, 2014, at 12:29 PM, Harbs <harbs.lists@gmail.com>
wrote:
>>>>>>> 
>>>>>>>> I took a little break on this to deal with some other crises.
>>>>>>>> 
>>>>>>>> I found where it’s going off:
>>>>>>>> 
>>>>>>>> In BaseCompose.fitLineToParcel() this check was failing:
>>>>>>>> 
>>>>>>>> 			// check to see if we got a good line
>>>>>>>> 			if (Twips.to(_lineSlug.width) != _curLine.outerTargetWidthTW)
>>>>>>>> 				return false;
>>>>>>>> The reason it’s failing is because the _lineSlug width
does not match
>>>>>>>> the new width of the line. (The first column/parcel is wider
than the
>>>>>>>> second.)
>>>>>>>> 
>>>>>>>> When it fails, the composer tries to keep getting the next
line and
>>>>>>>> upping the line absolute start but the _currentElementOffset
does not
>>>>>>>> get increased until we get an error.
>>>>>>>> 
>>>>>>>> So, I’m back to my original question. What’s the correct
way to deal
>>>>>>>> with this situation? I’m not 100% sure how line slugs and
TexFlowLines
>>>>>>>> are supposed to interact.
>>>>>>>> 
>>>>>>>> Any suggestions?
>>>>>>>> 
>>>>>>>> On Nov 7, 2014, at 10:34 AM, Harbs <harbs.lists@gmail.com>
wrote:
>>>>>>>> 
>>>>>>>>> A bit more progress: It looks like things go off where
the text flows
>>>>>>>>> from one container into another mid-paragraph…
>>>>>>>>> 
>>>>>>>>> (Sorry for polluting the mailing list with this. I’ll
try to be quiet
>>>>>>>>> until I figure it out…)
>>>>>>>>> 
>>>>>>>>> On Nov 7, 2014, at 9:55 AM, Harbs <harbs.lists@gmail.com>
wrote:
>>>>>>>>> 
>>>>>>>>>> It’s pretty big.
>>>>>>>>>> 
>>>>>>>>>> It consistently gets out of whack at the end of the
second paragraph.
>>>>>>>>>> I’m getting closer to where it’s going off…
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Nov 7, 2014, at 1:01 AM, Alex Harui <aharui@adobe.com>
wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 11/6/14, 2:02 PM, "Harbs" <harbs.lists@gmail.com>
wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> I think it’s _curElementOffset which gets
updated.
>>>>>>>>>>>> 
>>>>>>>>>>>> It does look like something is getting out
of sync. I’m just not
>>>>>>>>>>>> sure yet
>>>>>>>>>>>> what. This is one of those areas that’s
way too fragile IMHO… Every
>>>>>>>>>>>> time
>>>>>>>>>>>> I’ve run into these kinds of issues it’s
taken me days to figure out
>>>>>>>>>>>> exactly what’s off.
>>>>>>>>>>> 
>>>>>>>>>>> Is the paragraph huge?  In the past I simply
have to watch each line
>>>>>>>>>>> get
>>>>>>>>>>> created, figure out what is in the line, and
how much the offset
>>>>>>>>>>> should
>>>>>>>>>>> change and verify it changed.  This was when
I was dealing with some
>>>>>>>>>>> unicode character issues where an atom could
be made of more than one
>>>>>>>>>>> character.
>>>>>>>>>>> 
>>>>>>>>>>> -Alex
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Mime
View raw message