You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See GameMenu sample for example. LabelDelete is animated through the parent container resizing. At some point the parent container size is rounded so that the label position shifts one pixel right although the animation must smoothly move it to the left. This produces noticeable twitch.
Here are logs from Element::getUnclippedOuterRect_impl:
The fix might be in calculating parent-child rects without pixel alignment, and aligning only when render, but this may have unpredictable consequences. Need to think about it.
The text was updated successfully, but these errors were encountered:
I've found that disabling pixel alignment of problematic widgets almost solves the problem.
if (auto wnd = d_root->getChild("InnerButtonsContainer/PopupLinesCharacters/LabelDelete"))
wnd->setPixelAligned(false);
if (auto wnd = d_root->getChild("InnerButtonsContainer/PopupLinesCharacters/LabelSelect"))
wnd->setPixelAligned(false);
This produces a lot smoother animation, yet it doesn't eliminate logical twitching, and also it may work bad with texts, when the pixel alignment in not animated directions is desired. I.e. it is ok to disable horizontal pixel alignment when animate X axis, but Y must be aligned all the time, and when an animation ends, X must be aligned too. So this solution is only partial yet acceptable for basic cases.
See GameMenu sample for example. LabelDelete is animated through the parent container resizing. At some point the parent container size is rounded so that the label position shifts one pixel right although the animation must smoothly move it to the left. This produces noticeable twitch.
Here are logs from Element::getUnclippedOuterRect_impl:
They are obtained by inserting this code:
The fix might be in calculating parent-child rects without pixel alignment, and aligning only when render, but this may have unpredictable consequences. Need to think about it.
The text was updated successfully, but these errors were encountered: