Re: MXRoyale layout issues - questions/discussion
Long day... I stepped away from the keyboard and thought I had finished
that when I returned.
But this: ' although I know it's not a ' needs ''one:one mapping for
features/behavior" on the end (or something like that!)
On Sat, Jun 6, 2020 at 7:13 PM Greg Dove wrote:
>
> Yeah, that is the sort of thinking that I was trying to make work with
> what is there already (and yes it does seem like maybe something else is
> missing). Apart from simple size changes, it is the change on measuredSize
> after layout has happened in the child that I think some parents *might* be
> interested in when their children are containers with percent dimensions
> ('flexible' children I think is how they are described in some Flex code -
> this sort of makes me think of css Flexbox a bit when I look at what the
> BoxLayout stuff is doing, although I know it's not a ).
> But I am probably only scratching the surface here, you have the
> experience with this stuff.
> In terms of plumbing, one thing I pondered about would be whether MXRoyale
> layouts could form their own tree where they connect/detach directly to
> eachother as part of addChild/removeChild so that it is almost like a tree
> in parallel with the display tree.
> Maybe that could be a structure where they talk to each other directly up
> and down the tree with measurement and layout order somehow optimized. I
> think it still would not be as efficient as using the 'temporal buffer' of
> the Flex life cycle, with enterFrame or with 'requestAnimationFrame' but
> maybe it could be a little better... not sure, was just a thought and I
> know it seems like a radical change, so maybe that alone rules it out.
>
> I was going to drop another zip into the github issue. It occurred to me
> that it might be easier for you to test if I just put the changed files
> into the test app fileset as a monkey patch. That way you can mess with
> them locally more easily if you want to make quick changes and retest,
> without recompiling MXRoyale. (I was doing this a bit with GridItem/GridRow
> today in the app I am working on, where I have the monkey patch approach
> and it's quite a bit faster when testing changes).
>
> A little aside: one other thing I think I noticed today... I think mx
> Image has a 'layoutNeeded' dispatch on image load. That makes sense. But I
> think I saw that it is a bubbling event. Is that correct? Would this call
> layoutNeeded all the way up to SystemManager for a deeply nested Image (I
> did not check if it does yet)?
>
> Thanks again for looking at this. If I can help by creating more test
> cases or looking into anything specific in more detail, let me know.
> Greg
>
>
>
>
>
>
>
> On Sat, Jun 6, 2020 at 6:30 PM Alex Harui
> wrote:
>
>> I hope to have time tomorrow.
>>
>> Looking quickly at the things you've tried to fix the problem, it occurs
>> to me that the piece that is probably missing in MXRoyale is the
>> propagation of something like invalidateSize() instead of just
>> "layoutNeeded". My thinking is that in the general case the child can't
>> really know that because something about the child changed that the parent
>> needs to run a new layout and especially the parent of that parent.
>>
>> So some new plumbing may be needed where, when a component changes in a
>> way that its measured or explicit size had changed (as opposed to the size
>> change from the parent laying out the child), that some sort of
>> layoutMightBeNeeded is sent to the parent which then uses its measurement
>> code and explicit sizes to determine whether its size has changed and
>> propagates a layoutMightBeNeeded to its parent. But if it decides its size
>> has not changed, it would then run layout which should start the parents
>> laying out children.
>>
>> We'll see if the test case points in that direction.
>>
>> HTH,
>> -Alex
>>
>> On 6/5/20, 3:05 AM, "Greg Dove" wrote:
>>
>> Hi Alex, thanks for the detailed explanation and offer to take a
>> look, for
>> now some quick replies inline please add questions in the github
>> issue
>> if you want more details about anything I did so far.
>> thanks
>> Greg
>>
>> On Fri, Jun 5, 2020 at 6:50 PM Alex Harui
>> wrote:
>>
>> > Greg,
>> >
>> > I think this thread got forked somehow. If you have a simple test
>> case I
>> > can try to look at it this weekend.
>> >
>> > Thanks. I added issue #849 [1] which should give you something to
>> look at.
>> I suggest you open the Flex build in a browser and then compare
>> things to
>> it in Royale. There are 2 royale builds as well with the same code in
>> the
>> other 2 zips. One without the modifications to MXRoyale and one with.
>> The
>> 'one with' zip also has the modified MXRoyale files, so you should be
>> able
>> to drop them in and overwrite in your local MXRoyale and build to
>> test/review/change what I did. I'm the first to admit that I do think
>> it
>> doesn't feel right. But so far at
Re: MXRoyale layout issues - questions/discussion
Yeah, that is the sort of thinking that I was trying to make work with what
is there already (and yes it does seem like maybe something else is
missing). Apart from simple size changes, it is the change on measuredSize
after layout has happened in the child that I think some parents *might* be
interested in when their children are containers with percent dimensions
('flexible' children I think is how they are described in some Flex code -
this sort of makes me think of css Flexbox a bit when I look at what the
BoxLayout stuff is doing, although I know it's not a ).
But I am probably only scratching the surface here, you have the experience
with this stuff.
In terms of plumbing, one thing I pondered about would be whether MXRoyale
layouts could form their own tree where they connect/detach directly to
eachother as part of addChild/removeChild so that it is almost like a tree
in parallel with the display tree.
Maybe that could be a structure where they talk to each other directly up
and down the tree with measurement and layout order somehow optimized. I
think it still would not be as efficient as using the 'temporal buffer' of
the Flex life cycle, with enterFrame or with 'requestAnimationFrame' but
maybe it could be a little better... not sure, was just a thought and I
know it seems like a radical change, so maybe that alone rules it out.
I was going to drop another zip into the github issue. It occurred to me
that it might be easier for you to test if I just put the changed files
into the test app fileset as a monkey patch. That way you can mess with
them locally more easily if you want to make quick changes and retest,
without recompiling MXRoyale. (I was doing this a bit with GridItem/GridRow
today in the app I am working on, where I have the monkey patch approach
and it's quite a bit faster when testing changes).
A little aside: one other thing I think I noticed today... I think mx Image
has a 'layoutNeeded' dispatch on image load. That makes sense. But I think
I saw that it is a bubbling event. Is that correct? Would this call
layoutNeeded all the way up to SystemManager for a deeply nested Image (I
did not check if it does yet)?
Thanks again for looking at this. If I can help by creating more test cases
or looking into anything specific in more detail, let me know.
Greg
On Sat, Jun 6, 2020 at 6:30 PM Alex Harui wrote:
> I hope to have time tomorrow.
>
> Looking quickly at the things you've tried to fix the problem, it occurs
> to me that the piece that is probably missing in MXRoyale is the
> propagation of something like invalidateSize() instead of just
> "layoutNeeded". My thinking is that in the general case the child can't
> really know that because something about the child changed that the parent
> needs to run a new layout and especially the parent of that parent.
>
> So some new plumbing may be needed where, when a component changes in a
> way that its measured or explicit size had changed (as opposed to the size
> change from the parent laying out the child), that some sort of
> layoutMightBeNeeded is sent to the parent which then uses its measurement
> code and explicit sizes to determine whether its size has changed and
> propagates a layoutMightBeNeeded to its parent. But if it decides its size
> has not changed, it would then run layout which should start the parents
> laying out children.
>
> We'll see if the test case points in that direction.
>
> HTH,
> -Alex
>
> On 6/5/20, 3:05 AM, "Greg Dove" wrote:
>
> Hi Alex, thanks for the detailed explanation and offer to take a look,
> for
> now some quick replies inline please add questions in the github
> issue
> if you want more details about anything I did so far.
> thanks
> Greg
>
> On Fri, Jun 5, 2020 at 6:50 PM Alex Harui
> wrote:
>
> > Greg,
> >
> > I think this thread got forked somehow. If you have a simple test
> case I
> > can try to look at it this weekend.
> >
> > Thanks. I added issue #849 [1] which should give you something to
> look at.
> I suggest you open the Flex build in a browser and then compare things
> to
> it in Royale. There are 2 royale builds as well with the same code in
> the
> other 2 zips. One without the modifications to MXRoyale and one with.
> The
> 'one with' zip also has the modified MXRoyale files, so you should be
> able
> to drop them in and overwrite in your local MXRoyale and build to
> test/review/change what I did. I'm the first to admit that I do think
> it
> doesn't feel right. But so far at least it does make a bunch of code
> work
> in one app with a lot of deeply nested layouts that was not working
> before.
> It certainly does not make everything work. But it helps quite a bit.
> Certainly appreciate any review/consideration. I am really keen to
> collaborate on a solution that makes sense for most here.
>
> I don't doubt that the changes you propose work for you, but they
Re: MXRoyale layout issues - questions/discussion
I hope to have time tomorrow. Looking quickly at the things you've tried to fix the problem, it occurs to me that the piece that is probably missing in MXRoyale is the propagation of something like invalidateSize() instead of just "layoutNeeded". My thinking is that in the general case the child can't really know that because something about the child changed that the parent needs to run a new layout and especially the parent of that parent. So some new plumbing may be needed where, when a component changes in a way that its measured or explicit size had changed (as opposed to the size change from the parent laying out the child), that some sort of layoutMightBeNeeded is sent to the parent which then uses its measurement code and explicit sizes to determine whether its size has changed and propagates a layoutMightBeNeeded to its parent. But if it decides its size has not changed, it would then run layout which should start the parents laying out children. We'll see if the test case points in that direction. HTH, -Alex On 6/5/20, 3:05 AM, "Greg Dove" wrote: Hi Alex, thanks for the detailed explanation and offer to take a look, for now some quick replies inline please add questions in the github issue if you want more details about anything I did so far. thanks Greg On Fri, Jun 5, 2020 at 6:50 PM Alex Harui wrote: > Greg, > > I think this thread got forked somehow. If you have a simple test case I > can try to look at it this weekend. > > Thanks. I added issue #849 [1] which should give you something to look at. I suggest you open the Flex build in a browser and then compare things to it in Royale. There are 2 royale builds as well with the same code in the other 2 zips. One without the modifications to MXRoyale and one with. The 'one with' zip also has the modified MXRoyale files, so you should be able to drop them in and overwrite in your local MXRoyale and build to test/review/change what I did. I'm the first to admit that I do think it doesn't feel right. But so far at least it does make a bunch of code work in one app with a lot of deeply nested layouts that was not working before. It certainly does not make everything work. But it helps quite a bit. Certainly appreciate any review/consideration. I am really keen to collaborate on a solution that makes sense for most here. I don't doubt that the changes you propose work for you, but they make me > nervous although I'm not the best at reading code and understanding what it > does. Here's a brain dump on layout in case it helps. > > So far they work better 'for me' I agree. But I think you probably know me enough by now to know that if I am confident that I have a contribution that is objectively good (passes unit tests compared with swf is my normal benchmark) then I will add it. Part of the reason I started this discussion is because I feel a bit the same way here. I am still learning this stuff and figuring things out, so I am not pushing it because I don't want to inflict anything that is not an objective improvement on others. In terms of describing it, the main thing I think, is that the view checks when layout happens if there was a size change since last time layout ran, or if there was a change in size during the current run. Then there is some somewhat awkward checking to see if the parent might be interested in this because there is some 'sizedToContent' aspect to it (which includes a percentage variation on that check). If we think it is relevant, then request the parent to layout. Is this likely to do it sometimes when it is not needed, I suspect so. But so far it has not caused any problems in the codebase I am working with. I'm also working on the Grid related stuff, but you could probably just ignore that for now and focus only on the BoxLayout stuff. In Flex, parents always size their children. The children probably > shouldn't override that size or if they do they have to be careful that it > doesn't trigger the another layout in the parent in a way that you run > layout forever (a "layout loop"). In Flex, because of the LayoutManager > running on frame events, that generally doesn't freeze the UI and I have > seen situations where the LayoutManager never goes idle even though the app > appears to be running fine. There is also the case where the first layout > pass results in scrollbars which causes children to adjust and results in > the removal of scrollbars and that loops forever with the scrollbars > blinking on and off. In Royale, there is a greater chance of hanging. > > Also in Flex, with the LayoutManager, EVERY widget added itself to the > LayoutManager ensuring validation in a particular order, enforcing the > "parents size
