5 ms·

Eats one cpu core for me and makes the fan blow loudly. Which is why I never like these things.

• est 15y ago
  Funny, half year back the same bunch of people said the same thing to Flash. Now imagine a world where every banner or sidebar is full of HTML5 canvas animation ads.
  • melling 15y ago
    Firefox takes one core, while Chrome seems to split it across two cores, with a lower combined CPU utilization. I'm using the Nightly's for both browsers. With open source technology we get multiple implementations and a lot more people working to improve the technology.
    • est 15y ago
      > multiple implementations Remember Android fragmentation? Talk about open source as golden hammer to solve problems.
      • seanp2k2 15y ago
        Android fragmentation is not the same matter that was being referred to here. A better analogy might be Android and MeeGo or OpenMoko. Having a real choice is great in my opinion, and having three mainstream browsers (one open, one mostly open, and one totally closed) to choose between is awesome.
    • zobzu 15y ago
      That's odd, I use current Aurora and Chromium dev channel. Well, on Linux. Both use only one core for the browser, and Xorg uses "another core". Firefox uses 10% more CPU and the animation is butter smooth. Chromium uses 10% less CPU and the animation is a little choppy. It looks like Chromium is throttling or something. None of them use more than 40% CPU on the core used. Video driver is intel i915, acceleration works.
  • ugh 15y ago
    canvas { display: none !important; }
    • bzbarsky 15y ago
      This doesn't help that much, almost certainly. It prevents having to recomposite the canvas to the page, but the drawing to the canvas still has to happen....
      • ugh 15y ago
        I would very much hope that browsers don't implement canvas that way. Surely no one can be that stupid?
        • halter73 15y ago
          What if the following line is executed after the hidden canvas's context has been modified? canvasElement.setAttribute('style', 'display:inline !important'); According to you, non-stupid browsers should have ignored the previous updates to the canvas to save CPU time. Maybe the browser could keep a record of all of the calls made to the canvas API while the canvas is hidden and then execute them when the canvas element becomes unhidden, but that seems clever to me. I certainly wouldn't call implementors of the canvas API that don't do this stupid. In fact, there are probably good reasons not to do this. For example, if a web app makes frequent updates to a small hidden canvas, keeping a record of all the calls instead of simply executing them could end up using way too much memory. If a browser simply ignores updates to the hidden canvas, it would be breaking standards.
        • bzbarsky 15y ago
          You pretty much have to implement it that way. Not only because the canvas can later be shown, as halter73 points out, but also because of the getImageData API, which allows one to extract the pixel data from a canvas that's not being shown any time you feel like it. Also, a hidden canvas can be drawn to other canvases via drawImage, can be serialized to a data: URI at any time and so forth. So you really do need to be able to produce the right pixel data on demand. That means either doing the drawing when told to draw or buffering up the drawing commands (which can get pretty complicated, because some of them depend on the style of the canvas at the time the draw happened, so you either have to cache a bunch of style information or flush the drawing command buffer when style information changes or ... something). And as halter73 points out, it's very easy to end up with an effective memory leak when doing this sort of buffering.
• angstrom 15y ago
  Have to simulate the wind somehow...
  • xpose2000 15y ago
    nice
• resnamen 15y ago
  Google loves its users and wants you to stay warm.