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

Starting with 6.5.x, graphics behave differently than before #8623

Closed
adam-savard opened this issue Aug 30, 2022 · 3 comments · Fixed by #8832
Closed

Starting with 6.5.x, graphics behave differently than before #8623

adam-savard opened this issue Aug 30, 2022 · 3 comments · Fixed by #8832
Assignees
Labels
📢 Accepting PRs Would welcome a PR from the community. 🤩 Good First PR Indicating to new contributors a PR is simple/easy. Things like documentation or type fixes.

Comments

@adam-savard
Copy link
Contributor

I've attached a JS Fiddle to show what can go wrong in existing codebases:

https://jsfiddle.net/awn97mop/9/

The gist of this is, starting with 6.5.x, PIXI.Graphics calculate height/width differently than they did before, which I believe is due to this pull request (though I could be wrong about the cause, it feels like a bounds calculation thing!). When graphics are passed a fill of alpha 0 and no line style, they assume the graphics object has a height/width of 0.

I'm not suggesting that this be changed, as technically this does make sense to me. But, it did make upgrading to the newest version of PIXI a little frustrating today as I had to figure out what had changed between versions enough to cause this.

I'm putting this out there so that perhaps this can be spread through the official channels, or so that anyone else that decides to upgrade to the latest version and experiences a similar "what happened" moment has a point of reference.

The solution for us was to not use a fill with alpha 0 when there was also no linestyle. Not a complicated solution, and probably better in the longrun.

@dev7355608
Copy link
Collaborator

The bounds determine the width and height of the object including the scale of the object. The bounds should be minimal and contain the entire graphics always. Neither was true before 6.5.x. Now it's based on the actual geometry that is generated. But no geometry is and was generated for 0 alpha parts of a graphic. So any full transparent parts are not included in the bounds. Maybe they should, but then we would need to compute geometry for those parts that don't need to be rendered.

@adam-savard
Copy link
Contributor Author

@dev7355608 I don't really have a horse in this race since library-side, we just do whatever we need to do. Is this changed behavior documented anywhere beyond the PR and this ticket? Just thinking about anyone else that does an upgrade that might run into similar issues.

@bigtimebuddy
Copy link
Member

There probably should be a note about this new behavior in the API docs (probably in the constructor doc). Maybe something like this:

Since 6.5.0, shapes or strokes drawn with full transparency (alpha: 0) are not considered when calculating bounds for the Graphics. Transparent shapes/strokes are not rendered and therefore ignored when generate geometry.

Suggestions or PR welcome!

@bigtimebuddy bigtimebuddy added 📢 Accepting PRs Would welcome a PR from the community. 🤩 Good First PR Indicating to new contributors a PR is simple/easy. Things like documentation or type fixes. labels Sep 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📢 Accepting PRs Would welcome a PR from the community. 🤩 Good First PR Indicating to new contributors a PR is simple/easy. Things like documentation or type fixes.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants