-
Notifications
You must be signed in to change notification settings - Fork 823
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
Handling getBounds in a similar way to the classic Display List #1033
Comments
Instead of modifying Starling, you could create a utility function that wraps Starling's getBounds() in a try/catch. When an error is thrown, you could provide the fallback result. You'd need to modify the calls to getBounds() to call the utility function instead, but it would allow you to easily update Starling in the future without worrying about maintaining a fork. I'm not implying that Daniel won't want to make this change, of course. It's just a suggestion that came to mind while reading your description. |
I can definitely look into that! I can understand that it simplifies the porting process if those methods behave the same. Although, could you maybe explain a case where you ran into this? Do those bounds you are receiving in such a case even make sense? |
@joshtynjala Thanks for the suggestion! I thought about it, but I'd rather not add more to the current complexity of our project :/ @PrimaryFeather We found this particular issue in a system displaying character name above their head. In some cases we were already displaying their name while they were not yet on the stage. In that case the tooltip was generated and just put in the top left corner of the screen outside the view until the character was added to the stage. We could modify that system to make sure to request the bounds of the character only if he's added to the stage, but we'd rather not modify a functional system if we can. There are also several other calls to getBounds in other part of the code, where this could happen as well. |
Currently in Starling, if we do a
source.getBounds(target)
wheresource
andtarget
have no common parent, we end up with an exception thrown from DisplayObject.findCommonParent(). This can happen when one of them has not been added to the stage for example.But doing the same in the classic Display List seem to return the bounds from the highest parent of
target
instead from the tests we did.This difference makes it harder to port to Starling an application using flash.display classes relying on this method. Would it be possible to reproduce the same behaviour in Starling ?
We have already modified Starling to support it on our branch, I'll push that commit on GitHub once that ticket has been submitted, and I can do a pull request if you are interested.
The text was updated successfully, but these errors were encountered: