-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intrinsic height not updated on resizing children #16
Comments
Hi Eric, Thanks for the report, and yeah, not good. I want to get this fixed. I won't have a chance to take a look at this until maybe tomorrow night, but definitely by the end of next day. As far as where to look, it will have to do with the render objects. The parent-child dance all takes place in here: https://github.com/madewithfelt/flutter_layout_grid/blob/master/lib/src/rendering/layout_grid.dart. The one thing I can think of is that when a parent asks a child to layout, the parent can indicate if its (the parent's) layout should be invalidated if the child changes size in the future. I suspect that I'm saying that I'm not interested indiscriminately, but obviously intrinsic size is an instance where we should be. If you poke at this before I do, any of your findings would be much appreciated. A simple repro repo would also be great, but I understand the steps you've provided in any case. |
Yeah, took a quick peek, and that's exactly what's happening:
Good quick test might be to set Anyway, take a look if you've got cycles, but in any case I'll look soon. |
@erickok, the new changes to Dart/Flutter are giving me some issues. What version of Flutter are you on? |
Just changing that line into
doesn't do anything yet. But I'l see if I understand what is going on. I am on Flutter 1.22. To run you code I did have to set up a minimal mobile Flutter target as I have no macosx target working in my Flutter install. |
Oh and loads of thanks to helping out! |
Happy to. I ran a few initial tests, and I'm not hitting the problem yet. Here's what I'm working with: Looks like the grid is changing size when the child does, which doesn't make sense really...so I'm definitely missing something. What I need is a clear test failure. |
Better than a gist, here's the branch: https://github.com/madewithfelt/flutter_layout_grid/tree/intrinsic-size-problems I'm off to bed. I'll go deeper tomorrow. |
Thanks for trying! I just tried myself with a widget very similar to yours - a
You see it first getting a height equal to the (available) width, and when the fade animation is done the height adjusts to something smaller (yet still incorrect). |
OK, going to figure this out today. |
Hey @erickok, Sorry for dropping off. Been really busy with work. I'm hoping to have a chance to look at this very soon. I'll keep you posted. |
Hi @erickok, Sorry for the long long wait, but I have the rest of the day to work on all things |
OK, so I got that code sample you gave me running, confirmed that the weirdness is grid's fault, and I think I see what I'm doing wrong. Still thinking through what "right" would look like. I need to do some testing with the CSS equivalent. |
https://codepen.io/shyndman/pen/RwGejeQ ^ This is an approximation of what's going wrong. |
The grid is asking that image child, "how tall would you be if you filled the entire column", and it's saying "hella tall!!". Then the grid accommodates by changing its height. But then when the grid actually asks the image to render, the image renders at its intrinsic size instead of filling the column, and we're left with a big gap on the bottom. The same goes for the placeholder image, which has a different aspect ratio than the image we're loading, so we see odd scaling effects on that bottom gap. |
So I'm clearly missing a piece here. Going to dive into Flutter source and find it. |
OK, I have something working that feels reasonable. It deviates from CSS Layout Grid somewhat, because on closer reading the sizing concepts differ between the two systems. I have to figure out if the differences can be reconciled, or otherwise refactor the codebase to be more Flutter-y. I'm leaning towards Flutter-y, but need to sleep on it. Edit: Turns out it's not quite there. I'm finding edge cases. The core sizing algorithm definitely needs a bit of a Flutter-specific rethink, which should actually simplify it quite a bit. But I'm free all day tomorrow too, so this is getting done!!! |
Still on it. Going to get there. Built up a bunch of diagnostics today, so I can get this thing as close to CSS as possible. |
Keeping with it tomorrow. I'm excited to get this thing humming. :) |
The latest: Getting there. :) |
OK, here we go. Last day. |
So @erickok, I think this works properly now. Feel free to reopen if there are issues. |
When using
IntrinsicContentTrackSize
s the intrinsic height of a row is calculated based on its children, but seemingly only once. When a child resizes, the intrinsic height is not updated I believe. This is especially onbious when using image widgets inside such rows:The height of this row is incorrect when the image is shown. Adding a pre-specified size (height) to the image will cause the row to size correctly, but it is not always viable to known the size upfront.
Another way to see this problem is by replacing the
SingleChildScrollView
in the above example to be anIntrinsicHeight
. The row will be 0px high, as the height is not updated.Any solution or workaround is greatly appreciated! Or even hint on where to fix this in code, as I have tried but don't understand yet when a recalculation should and can happen.
cf Sub6Resources/flutter_html#456
The text was updated successfully, but these errors were encountered: