Here is also a link that can help you decide which CSS properties trigger layout, paint, and compositeĬhanging top, right, bottom, left alters the geometry of the element. Otherwise the browser will have to constantly repaint. Also try removing box-shadow and text-shadow to improve performance. Layout and painting are very expensive to recalculate. I see that it is causing a long rastersize repaint that has to perform 3 paint passes just to render the text in one frame Which is a child of a parent that your transforming. In your elementsymbolmatch.css i see that the browser has to rasterize your text due to the text-shadow you have on your text elements (. you should see a dramatic change in performance, especially on the ipad.īy using top and left your causing the browser to constanly have to relayout and then repaint which is why you are seeing that jank (lost frames) on the iPad.
#Clip box ipad code#
Once you follow Rodrigos advice on changing your GSAP code to use x instead of left and use y instead of top. it is causing massive repaints of the whole screen. Since you have a box-shadow, a gradient, and border-radius on your highest most div #backdrop. I just got done debugging your learning game on iPad and found some things: Thanks for any additional info? When I have more time I will try and debug your example on the iPadįirst off ketz, great learning game. what parts or steps of your learning tool (pretty cool by the way) are skipping, this way we can narrow down where your seeing this on the iPad: But you will see as you test that usually adding or removing a CSS property, and/or changing a CSS property value can help you in getting cross browser rendering of 2d and 3d transforms. If you have the will, you'll find the way. Especially when to use 2d or 3d transforms, since various CSS properties can workaround these browser rendering bugs. So it is always in flux.īut IMHO, Im of the mind set that set if the browser supports 3d transforms, then to never let the browser dictate to me when i should or shouldnt use something due to their buggy implementation. Chrome keeps fixing and then breaking their text anti-aliasing of transformed elements, an on going webkit bug. Sometimes you need to set the initial scale less than a zoom factor of 1, and then have your actual width and height a little larger for the zoom factor less than 1. You will get better perfomance with no relayout and relpaint cost that is associated with using top and left.Įspecially when scaling in webkit based browsers. That is why x and y are always better than top and left. Using left and top will aways force the browser with expensive layout and paint operations. Also adding slight rotations, translateZ (z), and or skewX can help with these blurry browser bugs. But they can be corrected by using a combination of other CSS properties like perspective, transformPerspective, transformStyle:preserve-3d, etc. MindGamer, The blurry animations usually happens due to browser bugs and how they handle 3d transforms, especially in Chrome with text. Give that a try and let us know how it goes. Although the main problems seem to be happening when the timer hasn't started or is already done, but you'll have to play with it and see what happens.Īnother option would be to store the animations that are giving you trouble and take them to the end and then back to the beginning in order to force the rendering of the values, that could save some CPU cycles and speed things up, like this:
During those 0.5 seconds that the CPU gets too busy the timer will still be running, so basically that will mean that the user will have less time. For example if the animation has to last 0.5 seconds, and when the animation is on the 0.2 seconds mark, the CPU chokes for 0.5 seconds, your animation will restart after the CPU gets un-choked and the missing 0.5 seconds of the animation will complete. The lagSmoothing parameter shouldn't affect the timer, since it works in a different areas so to speak, but keep in mind that with lagSmoothing your animations will last as long as they are intended. Although the best way to know is testing and testing.
Using X and Y are normally 0 when the elements are first rendered on the screen and for what I saw on your game, most elements have an absolute position, so it shouldn't be any difference.
0 kommentar(er)
