-
Notifications
You must be signed in to change notification settings - Fork 179
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
Possible bug(s) in PaintManager.repaint? #32
Comments
From one hand paint manager is very carefully overviewed and tested code, since it has big impact to entire zebra functionality. From another hand the first snippet with "return" also look not clear to me. Have to check why it is necessary (or unnecessary).
I would appreciate very much any snippet you can provide to illustrate the problem. PS: nice to see you can follow in source code so deep :) |
Thanks for the quick response! I see now that I might not have been implementing my custom component in the intended way. I was trying to do some animation, and the bug I had was that through a chain of events, a call to In this case I can fix the problem in my code. At first I thought setting Perhaps instead of ignoring these silently, though, there should be a warning? That would have helped me in this case. I'm thinking that valid uses (if there are any) of calling repaint within a paint method can be implemented by calling repaint asynchronously (or just ignoring the warning). I will also see if I can construct a snippet to illustrate the first issue with the early return. |
In general calling repaint method from paint manager "paint callback" (set with setTimeout()) is not forbidden. Paint manager "paint callback" does two important things:
At the validation stage validated UI components can call repaint method as many time as they want and need. Actually it is not avoidable, since validation often means applying layout managers what causes UI components resizing and relocating. Called at the validation stage "repaint(...)" method will update dirty area of the rendered canvas. So at the second stage (paint) paint manager will have valid and up-to-date dirty area. At the second (paint) stage calling repaint method is too late. It also will cause canvas dirty area updating but painting process has already been initiated and the dirty area updates will not take effect. The rule is the following: don't call repaint method from a component |
By "paint method" I did mean one of
As for the early return in calculating dirty area, I realized that there are only two scenarios where the canvas will have a dirty area:
In the first case, it's fine to return early because a paint will happen soon anyway. In the second case, the repaint is already going to ignored (by the current logic), so it doesn't matter. Still, I feel like the code is a bit confusing as it stands. I'm planning to send you a pull request as a suggestion for clarifying the logic (no pressure to accept it, I understand if you don't want to make changes to this part of the code). |
Hi, whilst trying to implement a custom component, I noticed a few situations where my component would refuse to repaint properly (it would call repaint, but the repainting would be short-circuited somehow). Looking at the PaintManager.repaint function, there are two things that seem fishy to me. First, we have
It seems like there should not be an early return there, as we don't want to skip painting entirely; we just want to avoid calling MB.unite when unnecessary.
Second issue is that at the end of the function passed to setTimeout, we have
It seems to me that the last line is unnecessary, and in fact I tried commenting it out and things seemed to work OK. Actually, fixing the two issues described here seemed to solve my problem, although of course it could have broken something else.
Are these bugs? Can you explain what scenario the
canvas.$da.width = -1
is supposed to guard against? If needed, I can try to create some problematic examples to help you reproduce my issue, but this will take some effort, so I figured I would ask first. Thanks!The text was updated successfully, but these errors were encountered: