I agree we shouldn’t resize if multiline=true.
IMO it would be great to have Clint work on this.
I think the only thing not covered is what conditions we "give up" on. If
I understand correctly, it would be any multiline StageText greater than
16384 in width/height, or just 8192?
I could be wrong, but I think for multiline=false you could resize, but if
you don't want to bother handling that case that's fine with me.
And did we agree that if we hit these extreme cases we throw an error? Or
just output something to trace()?
Thanks,
-Alex
On 3/2/16, 6:36 AM, "Clint M" <cmod...@gmail.com> wrote:
>I agree with Om that we shouldn't be resizing them. If they're outside the
>bounds because of size it must be an absurdly large text based control and
>I think an error is appropriate to let the programmer know he's made an
>error.
>
>This control only uses these stageTexts to create bitmaps so it doesn't
>matter where they are in the global coordinate space. It only matters when
>a user clicks on the control and puts it in an edit state that the
>stageText needs to be positioned correctly over the Flex based component.
>
>Om, the pattern for this control should be similar to the pattern for the
>sfly page renderer when we had a single renderer off the edge of the stage
>that generated bitmaps that we reused.
>
>ScrollableStageText is using a StageTextPool and creating one StageText
>for
>each flex based ScrollableStageText. This creates a 1 - 1 mapping of
>StageTexts to ScrollableStageText instances. (i.e.
>100 ScrollableStageTexts = 100 StageTexts). It then tries to maintain the
>StageText's position over the ScrollableStageText
>instance using updateViewport()
>
>I think we can get away with 1 or 2 or maybe 3 StageText instances total
>for any Flex app that uses ScrollableStageText.
>
>One for making bitmaps positioned just off the stages viewable area.
>One for editing that's hidden until a control requests an edit state.
>Maybe one for focus change, but I'm not sure this is required yet as I'd
>like to reuse the control used for editing and might actually fix a
>focusManager based softKeyboard activation/deactivation bug I'm also
>looking at.
>
>In the case of a VGroup with 200 TextInputs that are 20px high and 25px
>apart (8200 px tall) there would still only be 3 StageText instances.
>
>This seems like it would be a better fix for the bug in question.
>
>Again I'm happy to make these changes and run them through a QA cycle here
>on my current contract. I just need a week or so to get to it.
>
>
>On Tue, Mar 1, 2016 at 2:46 PM, OmPrakash Muppirala <bigosma...@gmail.com>
>wrote:
>
>> On Tue, Mar 1, 2016 at 1:01 PM, OmPrakash Muppirala
>><bigosma...@gmail.com>
>> wrote:
>>
>> > On Tue, Mar 1, 2016 at 8:33 AM, Alex Harui <aha...@adobe.com> wrote:
>> >
>> >> Hmm. I may still be misunderstanding, but I thought this was a basic
>> >> clipping issue. So Clint is right about the goal of the math, but I
>> think
>> >> it doesn't matter if the StageText is on the visible portion of the
>> screen
>> >> or not. For example, a very wide StageText could start offscreen,
>>have
>> >> some of it on screen and more of it offscreen as long as no part of
>>it
>> >> goes out past -8192 or +8192.
>> >>
>> >> If that's true, then I think the code has to recognize that changing
>> the x
>> >> property MOVES the StageText's right side. IMO, you don't want to
>>move
>> >> the right side, so if you change .x, you have to change .width (but
>>not
>> >> vice-versa). The clipping code should just visit each of the four
>>sides
>> >> to make them fit within the allowed range and make adjustments
>>without
>> >> moving the opposite side.
>> >>
>> >> So, something like:
>> >>
>> >> if (x < -8192) {
>> >> var delta = -8192 - x;
>> >> x += delta;
>> >> width -= delta;
>> >> }
>> >> if (x + width > 8192) {
>> >> var delta = x + width - 8192;
>> >> width -= delta;
>> >> }
>> >>
>> >> Of course, I could definitely be wrong...
>> >>
>> >>
>> > The problem is if we change the StageText object's width, it will
>> > potentially affect the text that is getting rendered. A smaller width
>> > means that a wrap occurs earlier in the body of text.
>> >
>> > That is the crux of the problem. If the x or y of the stagetext is
>> > outside the allowed bounds, we can always move it without affecting
>>the
>> > text. When the width or height is outside the bounds (which also
>>causes
>> > the ViewPort rectangle to go outside the allowed bounds) we will have
>> this
>> > issue no matter what.
>> >
>> > I guess, we just need to throw an error in this case. I dont think
>>it is
>> > a common scenario to have such a large TextInput control.
>> >
>> >
>> There's also the case where a combination of x + width causes the
>>viewport
>> bounds to exceed the 8192 threshold. I am not sure how we would handle
>> this case.
>>
>>
>>
>> > Thanks,
>> > Om
>> >
>> >
>> >> -Alex
>> >>
>> >> On 3/1/16, 7:02 AM, "Clint M" <cmod...@gmail.com> wrote:
>> >>
>> >> >Well the key is… If you think about this in the _global_ (stage)
>> >> >coordinate
>> >> >space… anything outside the bounds of 0,0,stage.width,stage,height
>> won't
>> >> >be
>> >> >viewable to anyone so it should be safe in all cases to just
>>position
>> the
>> >> >StageText outside the viewable stage area and leave it there until
>>some
>> >> >part of it is viewable.
>> >> >
>> >> >If you're unable to position the StageText off the stage because
>>it's
>> too
>> >> >big. Raise an error about the limits.
>> >> >
>> >> >The math for the edge cases is most likely that the StageText Rect
>>is
>> >> >contained within the Rect that makes up the limits.
>> >> >
>> >> >So:
>> >> >x > -8192 && x + width < 8192
>> >> >y > -8192 && y + height < 8192
>> >> >
>> >> >However… I feel like the control is misbehaving.
>> >> >I think one of the goals of this control is to show a proxied bitmap
>> >> >instead of the actual StageText itself.
>> >> >So why does it create a StageText at the correct x,y at all?
>> >> >To generate the bitmap we can just have a single StageText off the
>>edge
>> >> of
>> >> >the stage.
>> >> >And then in the case of edit make a new one and potentially have one
>> more
>> >> >for the case of a focus change for a total of 3 instances of
>>StageText
>> >> >although I think I could get away with just 2 instances it might
>> actually
>> >> >solve a keyboard activate/deactivate bug I'm looking at as well.
>> >> >
>> >> >I intend to come back to this control to see if I can make it work
>>the
>> >> way
>> >> >I describe because I've been trying to use it as is for the past few
>> >> weeks
>> >> >and failed.
>> >> >
>> >> >There's also a bug with focus management and the way scroller's
>> >> >softKeyboardActivate handler is trying to ensure that the control
>>is in
>> >> >the
>> >> >viewable area before ScrollableStageText calls assignFocus.
>> >> >
>> >> >
>> >> >
>> >> >On Tue, Mar 1, 2016 at 2:28 AM, OmPrakash Muppirala <
>> >> bigosma...@gmail.com>
>> >> >wrote:
>> >> >
>> >> >> Hmm, I'm not sure if there is a good solution for this. Here are
>>the
>> >> >> scenarios which could trigger this behavior:
>> >> >>
>> >> >> <s:TextInput x="0" *y="10000"* width="100" height="100"
>> text="Hello"/>
>> >> >> <s:TextInput *x="10000" *y="0" width="100" height="100"
>> text="Hello"/>
>> >> >> <s:TextInput x="0" y="0"* width="10000" *height="100"
>>text="Hello"/>
>> >> >> <s:TextInput x="0" y="0" width="100" *height="10000"*
>>text="Hello"/>
>> >> >>
>> >> >> The StageText.viewPort has a hard limit of -8192 to 8191 for its x
>> and
>> >> y
>> >> >> values.
>> >> >>
>> >> >> Is there a good way to solve this for for all cases?
>> >> >>
>> >> >> Thanks,
>> >> >> Om
>> >> >>
>> >> >> On Tue, Mar 1, 2016 at 12:10 AM, OmPrakash Muppirala
>> >> >><bigosma...@gmail.com
>> >> >> >
>> >> >> wrote:
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>>
