-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Revert #24222 and simply use invalidate
instead of postInvalidate
#24990
Conversation
Hey there @albyrock87! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
* @param hasClip | ||
*/ | ||
protected final void setHasClip(boolean hasClip) { | ||
if (this.hasClip != hasClip) { |
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.
Why do we remove the if
? If the value for hasClip
hasn't changed, why does it need to run invalidate()
?
Does it actually need to be called in a different place in the stack? In .NET MAUI's C# layer, perhaps it would know what changed?
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.
@jonathanpeppers I've just done what you asked: revert your PR and use invalidate
instead of postInvalidate
.
That said:
- setting a boolean field value has very likely no impact on performance, so the
if
is kind-of useless - this method is being called from the C# layer when the
Clip
changes, that's why we always need to invalidate- calling it from C# would cause two JNI roundtrips for nothing
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.
setting a boolean field value has very likely no impact on performance
Setting the field isn't the question, but the fact that invalidate()
is called. Why do we need call invalidate()
if true
is set to true
? or false
set to false
?
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.
Because the clip path or the shadow details like color, radius,... have changed.
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.
we should call these methods something like invalidateShadow(bool willDrawShadow)
but it's a public API and I can't do that
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.
If the clip path or shadow changes, should those be the things that call invalidate()
?
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.
The reason to not move invalidate
call there is just to avoid two round trips on JNI. So this is just a naming problem in my opinion.
* @param hasShadow | ||
*/ | ||
protected final void setHasShadow(boolean hasShadow) { | ||
if (this.hasShadow != hasShadow) { |
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.
Same question here.
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.
Same answer here :D
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
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.
If this fixes a new issue, changing postInvalidate()
-> invalidate()
will solve the performance issue from earlier.
LGTM, will include the new aar as part of this PR. Waiting build to complete. |
/backport to release/8.0.1xx-sr9 |
Started backporting to release/8.0.1xx-sr9: https://github.com/dotnet/maui/actions/runs/11221159064 |
5b05cea
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
/rebase |
5b05cea
to
84c7791
Compare
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
/rebase |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
/rebase |
84c7791
to
c581c9d
Compare
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Description of Change
#24222 broke reaction to shadow / clip changes.
This PR brings back the original code while replacing
postInvalidate
withinvalidate
to avoid countless scheduled invalidations considering that MAUI only operates on platform views through the main thread.You can see more details in the issue's comments.
While CI regenerates the
aar
, we should commit the newaar
once this is merged, or as part of this PR.I've not included it for security reasons.
Issues Fixed
Fixes #24882