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
Draft: Rework item geometry #3115
Conversation
I know that i think about it, maybe trying to fix the tests could have help me find the issues... 😓 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't look at details yet, but it looks good from a first glance
@@ -89,8 +90,9 @@ macro_rules! fn_render { | |||
backend.draw_cached_pixmap( | |||
item_rc, | |||
&|callback| { | |||
let width = self.width().get() * $dpr; | |||
let height = self.height().get() * $dpr; | |||
let geo = item_rc.geometry(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally here we should get the size from the call to render that has it instead of doing that.
(because each call to geometry add possibly 4 property dependency we don't need)
But we can leave that as an action item for later.
Most commits are from you 😝 But thanks anyway. |
Yes, I was referring to the commit you added. |
OK so following breaking tests, I found an easier case to study (from export component Ui inherits Window {
in property <color> c: yellow;
background: black;
Rectangle {
x: 1phx;
y: 80phx;
width: 15phx;
height: 17phx;
background: red;
}
Rectangle {
x: 10phx;
y: 19phx;
Rectangle {
x: 5phx;
y: 80phx;
width: 12phx;
height: 13phx;
background: c;
}
Rectangle {
x: 50phx;
y: 8phx;
width: 15phx;
height: 17phx;
background: c;
}
}
} gives Output
where we should have And at some point with constant evaluation we should hope for something as simple as (in the spirit at least): Output
|
Do you know if this was caused by one of my commit, or caused by your change? |
I'm only sure it was not cause by the first commit (I though is was a flickable issue at first). I didn't try a bijection on other commits has I not sure it would even build/work. |
I guess we are missing a step needed by the addition of |
I see the problem: the So two options:
Option 1 is status qui as it used to be. But option 2 is great because it allow to optimize more now that we decouple the item geometry from their language properties. |
It does look OK on your last commit:
EDIT: and more importantly the result is visibly OK |
By the way |
Ideally we can remove them all indeed. (in the optimize_useless_rectangles pass) CacheRenderingData is another thing that was maybe not such a good idea to put there. and we may consider removing. |
7d06d29
to
0aae496
Compare
To better get familiarize with the code I tried solution 1 first (I want to do solution 2), it fix the rectangle bug. I will try to do solution 2 tomorrow. The |
Instead: add the viewport propety directly in the Flickable Simplifies the compiler's code generation a bit
(unused yet)
We need to account for the repeater count in the item sub-range
The WindowItem did not have a x or y before, so these property were unused for it's geometry(), but now it is used in the new item_geometry on the ComponentVTable. So make sure we don't initialize them
I would love to add a clippy disallowed method for this, but it's a generic type alias.
1e8bc2e
to
7035e5d
Compare
I'm moving forward (almost done) for the solution 2 for fixing the rectangle optimization. But at the time being, it ends up generating more properties, and I feel like more math optimization should be done afterward:
We could hope for only: |
Unfortunately, we can't do inlining with the current expression_tree::Expression because property references to inner value are not representable. That's why there is only const propagation pass and then a inline_expression pass that operate on the llr. Of course there is room form improvements. I have the feeling the use of "phx" is not so frequent, so this particular example might not be representative of real code.
Is it really more properties? Doesn't these new property used to b in a rectangle anyway? |
Not really, it's just more than it could be.
I just use one of the test case, you are probably right |
I'm not sure what you mean, but I trust you :p |
7035e5d
to
930be7e
Compare
Thanks for your work. I have taken your commit and put them in #3452 |
Sorry for abandoning my PR, I wasn't able to make time to finish it. Anyway glad to see that you managed to push it to the finish line ! |
Closes #1932
I'm creating this PR to share where I'm at. But it is still buggy...
The following for example does not work:
From a debug log using the interpreter after the flickable rework we have:
Output
And at the end:
Output
Clearly things goes wrong somewhere:
i-text-input-7
somehow get center to the viewporti-text-input-7
dimension are not set (should be bind to viewport)So still some debugging to do, but I'm tacking a break.