Jump to content

Rotation optimization


bokan
 Share

Recommended Posts

I just reviewed the code of Pixi.js and I think there's a point that deserve attention.

 

It is much faster to handle an object when it is not rotated/skewed. Its transform matrix is much simpler (doesn't require matrix at all) and lot of computation could be removed. Bounds computing is also much simpler.

 

I wonder if it's not worth implementing an optimization for this. It won't change the API at all, it will add very few code. Just a check for each objects, and saves a lot of code for non rotated objects.

 

I would like to know what people think about that. Do you use rotation on most of your objects or only few of them ?

 
Link to comment
Share on other sites

Sounds like a preoptimization that isn't really needed (at least not for general rendering cases).

 

PIXI.SpriteBatch._renderCanvas() seems to do what Bokan described already* was this premature optimisation?  ;)

 

*atleast when child.rotation % (Math.PI * 2) === 0, I mean shouldn't that check if the modulus value is between negative some epsilon value and plus that epsilon value**?

**I'm guessing that epsilon value could be fairly large, like maybe 0.00025 ( asin(1/4000) ) assuming you want to cover imperceptible rotation

Link to comment
Share on other sites

hey peeps!

 

As it happens I have been working on the update transform function this wknd :)

You can see it here: https://github.com/GoodBoyDigital/pixi.js/tree/dev-filters

I was rewriting it for a few other reasons but added the suggested optimization to the function too. Not sure how much extra speed it will bring but it certainly wont be slowing it down :)

Link to comment
Share on other sites

PIXI.SpriteBatch._renderCanvas() seems to do what Bokan described already* was this premature optimisation?  ;)

 

*atleast when child.rotation % (Math.PI * 2) === 0, I mean shouldn't that check if the modulus value is between negative some epsilon value and plus that epsilon value**?

**I'm guessing that epsilon value could be fairly large, like maybe 0.00025 ( asin(1/4000) ) assuming you want to cover imperceptible rotation

 

Yes, the whole point of SpriteBatch was to do every optimization so it makes sense there.

 

Good spot chg !

 

xerver : All optimizations are good to take when we claim being the fastest ! :)

 

I disagree with that, most optimizations come at a developer cost (maintainability, readability, etc). We make the choice to use optimizations not so we can yell about numbers, but so the library gets faster. If we reduce the core loop from 2ms to 1ms at the cost of convoluted code, then that isn't worth it to me.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...