I've developed HTML5 game with canvas and DOM elements. And I have problem with flickering DOM elements while playing. The problem occurs in mobile browsers, especially in Chrome.
My apps consists of full screen canvas and DOM elements as GUI (ie. popups). There is many objects rendered on canvas in loop. While playing suddenly DOM elements start flickering (not integrally but regular fragments). DOM elements are positioned absolutely and scaled on window resize by CSS3 (transform:scale).
I cannot publish the code because it's commercial project, but I attach screens below.
http://mywebpage.ovh.org/1.jpg
http://mywebpage.ovh.org/2.jpg
http://mywebpage.ovh.org/3.jpg
Does anyone know the reason and the solution?
Thanks in advance!
I don't think you posted any screenshots, but most likely because it is redrawing it without a buffer. I would take a look at double buffering, I know when I coded flash and java games back in the day buffers really solved a lot of the flickering.
Heres a previous question which may be helpful:
Does HTML5/Canvas Support Double Buffering?
edit: okay I see the screenies now, It's probably not double buffering, but CSS. I would double check your CSS for any thing like background-attachment: fixed or position: fixed, I know that sometimes gives flickering in Chrome.
Related
When using scaling to change the size of an HTML element containing text, the text jitters during the animation, but only if being animated with JavaScript libraries.
The jittering is most visible when the animation is slower and the text is smaller. I can't seem to figure out what causes it or how to get rid of it.
This jittering does not occur during CSS animations or animations using the fairly new JavaScript Web Animations API. It also doesn't seem to occur in some browsers. (On my iPhone)
To easily compare the different methods of animating the scaling of an element and how they appear, I made a CodePen for convenience. Before checking it out, note these points:
All the animations are using some form or imitation of the CSS property transform: scale(num); for the animation and have the same easing and duration so they can be compared more easily.
Although the jittering appears on macOS too, it is almost impossible to see on Macs with retina screens because of the high resolution.
The results I got are a reflection of the appearance of the animations on a Windows 10 machine in Google Chrome 59, although for me Microsoft Edge also showed the same results.
So my question is this: How can I prevent the text from jittering or becoming blurry when animating a scale property with JavaScript? How can I make the text in my JavaScript scale animations appear just as smooth as they do when using CSS?
You may be wondering why I don't just use CSS. The answer is because I'm frustrated with how limited CSS animation is. I would like to use advanced easing functions beyond the capabilities of a simple bezier curve (like Robert Penner's bounce and elastic functions), and use different easings on hover when the mouse enters and exits the element. This s completely my own opinion, but so far the only painless way I've found to do this is with JavaScript libraries. Besides their functionality relating to easing, most seem to offer many other capabilities which make animating much more effortless. If you know of a better way to get all the functionality I need please let me know!
What you are encountering are differences in a browser's layerizing strategy. You'll find that all the examples appear smooth in Firefox. That's because Firefox detects when script is changing a property that can animated using layers and creates a layer in response.
Although all browsers create layers when needed for declarative animations (CSS animations, CSS transitions, Web Animations API animations, and even SVG SMIL animations in some cases) not all browsers do it for Javascript animations. So, for those browsers you need to try to trick the browser into creating a layer (or, you could just file a bug on the browser, since it really should do this for you!).
Until recently, using will-change: transform was the recommended approach to get a browser to create a layer. However, Chrome changed its rendering strategy and now will-change: transform can produce very blurry results with scale animations in Chrome. Some people have succeeded in tricking Chrome to layerize at a higher resolution initially and then scaling their element down before animating. This is really unfortunate to have to do this and I can only encourage you to petition Chrome to fix this.
Also, the examples using "with HA" are not accurate. The CSS animation in (1) will also use hardware acceleration in every browser I know of--there's no need to add perspective in. Unfortunately, there is a lot of misleading information in this area (e.g. some articles claim animations can run on the GPU but that's simply not true). At the risk of self promotion, you might find an article I wrote on this last year helpful.
I am trying to animate lines going from left, right, top and bottom(lines should start from edges of the screen). Animation works fine in IE11 but not in Mozilla and Chrome. Other browsers I haven't tested. I used Adobe Illustrator to draw. http://codepen.io/Ljanmi/pen/WbyLWv
In Chrome and Mozilla(IE11 is fine and acts normal) if in Illustrator I set Object>Artboards>Fit To Artwork Bounds(minimizing Artboard size which I usually do when create or edit SVG) I get this result(even worse) - http://codepen.io/Ljanmi/pen/yyqVqz
I spent hours and hours trying to figure out on my own without success. I started topics on GSAP forum and CSS tricks forum(stackoverflow.com is limiting me to post only 2 links as a newcomer).
I used GSAP JS library for animating(generally very happy with GSAP) but animation behaves the same if I use CSS3 to animate. I concluded that it is not related to GSAP(viewbox size property seems to have little bit of effect here) , more likely to be related to SVG structure itself or browser compatibility or both. So I guess there must be some work around to make it work like I would like to. I most likely lack some SVG/HTML/CSS3 knowledge since I am not very experienced but trying to learn as much as I can. Thanks everybody for reading.
Add svg { overflow: visible } and it should work the same in all browsers (longer explanation below). If you want to see why the lines get clipped, add borders to the svg element.
Another way is to make sure the size of the svg matches what you want, e.g by using css.
All browsers except IE implemented hidden as the initial value for the overflow property for the <svg> element, as called for by the SVG 1.1 spec. SVG 2 has changed this for (outermost) inline svg elements, such that it requires what IE11 is currently doing. It will take some time before that gets changed in all browsers, so for now just add the overflow: visible rule and it should work correctly in all browsers.
I had some trouble with browsers still not showing the overflowed content for SVGs and found that this finally got past it:
svg:not(:root) {
overflow: visible !important;
}
I made a game where you can walk on a 2d grid world (Pokémon style) and currently you just hop from tile to tile instead of a nice walking animation in between.
I'm right now working on that walking animation, and it all works, except that the browser doesn't reflow/repaints fast enough.
If I closely zoom in on the sprite I can see the sprite moving and doing only half of the replaces he needs to do. This creates a lag feeling, which I obviously not want. So I googled today and learned about reflow and repaints and that the browsers stacks the animations until a certain time and then executes them in batches.
I want to avoid the stacking of animations so I searched on Google, and found a lot of hacks, which are not working for me, unfortunately...
I used hacks like requesting the offsetTop, hiding and showing the element, and some others which are easily to be found online. None of them worked.
I then learned here: http://dev.opera.com/articles/view/efficient-javascript/?page=3#reflow that the browser may reflow in the background, without making it visible. (probably why the hacks weren't working)
Do you have any way so I can make the browser visibly reflow?
On a web page, I'm scaling an <img/> tag.
To this end, I use the css3 transform scale function linked through jquery .animate method (https://github.com/louisremi/jquery.transform.js). All in all, result is good on Firefox and IE9. But under webkit browser (notably chrome 21), there's a big performance cost and the animation isn't looking good.
So, I take a look at the chrome devtool timeline. And the problem is definitly caused by the repaint of the <img/>, the time taken to repaint the image is incredibly long.
Just so you know, we don't access dom to often (never while animating), and we use requestAnimationFrame. The trouble really seems to live in the algorithm used by webkit to resize images. We added css -webkit-transform-style: preserve-3d;, this helped a bit, but not so much.
Do anyone have a hint on this ?
I am using text-shadow for all p and headline tags (2px white glow for better readability), everything works fine until page is scrolled and javascript changes absolute positioning on one element to fixed - which I want to stay visible.
Is there any way apart of changing style for opera to make it scrolled smoothly? overflow:auto is not working in this case...
Thanks
it's hard to say 100% without seeing the code, but I guess that the way you've styled this page makes Opera do a lot of reflowing and painting when it is scrolled, and the combination of styles will make this a very expensive operation. (It would be nice to see a jsfiddle or get a link to the actual page, this would also make it simpler to advice on possible workarounds).
There are various fixes you could try - like keeping the element you want on-screen styled with position:absolute and move it from JavaScript after scroll events, or simply avoid setting position:fixed in Opera and letting the element scroll away for better scroll performance.
However, I'd strongly recommend that you first report a bug to Opera. Why?
The reason and the genesis of the web is collaboration. It may not be obvious to (understandably) frustrated web developers struggling with browser bugs, but they have a responsibility for helping browser vendors improve when they find problems, thereby contributing to moving the web forward. A minority browser like Opera admittedly has less development and QA staff resources, but to some extent support from the user community and "normal" web developers makes up for this and makes it possible also for smaller players to develop in the Web ecosystem. I think that's one of the web's strengths and the real reason why no single corporation has been able to dominate it.
So please report your issues and problems :)
This is a problem with Opera, not any way you've written the code. Opera is a gigantic steaming pile of doo-doo with almost no market share, and you should use another browser.
That's basically all anyone could tell you here, unfortunately. I understand that everyone loves their browser of choice but some just don't handle these things well. Other examples: browser with a poor javascript engine rendering animations erratically and jerky, etc.