Skip to content
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

Open
rthery opened this issue Jun 21, 2018 · 3 comments
Open

Handling getBounds in a similar way to the classic Display List #1033

rthery opened this issue Jun 21, 2018 · 3 comments
Labels

Comments

@rthery
Copy link

rthery commented Jun 21, 2018

Currently in Starling, if we do a source.getBounds(target) where source and target 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.

rthery added a commit to Ankama/Starling-Framework that referenced this issue Jun 21, 2018
@joshtynjala
Copy link
Contributor

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.

@PrimaryFeather
Copy link
Contributor

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?

@rthery
Copy link
Author

rthery commented Jun 25, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants