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:
>> >>
>> >>
>>
>>
>

Reply via email to