canvas is incredibly fast. I think its 100% capable for anythign except 3d games.
You do realize that you can get a 2D and a 3D context from a canvas element, right?
In defense of
51–60 of 64 posts
Re: In defense of <canvas>
#52Earlier quoted context omitted.
It's up to the publisher to do that, I know that there will be a kindle edition, but am not certain of any other formats. I imagine all of them will be DRM'd, sorry. In the near future I will also have a performance chapter in a different book (written quite differently, and expecting more JS knowledge), but that title hasn't been announced yet. That text will have a DRM-free ebook for it, but you'll have to wait a l…
http://www.informit.com/store/html5-unleashed-9780672336270 Informit sells PDF, mobi and epub versions of all Pearson books. They print "From the library of Your Name" as a footer on every page but there's no additional copy protection as far as I know.
Thanks for sharing this link. For e-books I find PDF a superior format, as it maintains the original design and layout of the book best, while still having all the advantages of an e-book, searchable, etc. Appreciate that informit.com has that option.
Re: In defense of <canvas>
#53I really like this Soundslice canvas app. Why didn't Soundslice use Scalable Vector Graphics? CSS Animations would replace a whole heap of code: the entire requestAnimationFrame callback, for example, would be eliminated. Text rendering would be handled by the browser, instead of taking the performance hit of being rendered to the canvas bitmap every frame, so text rendering caching would not be necessary. Element st…
Hey -- I didn't spend much time exploring SVG, to be honest. It could very well be faster! And you're right that it would be much better on retina screens. I've had it on my to-do list to make the canvas implementation take the device pixel ratio into account, but it hasn't been a huge priority.
Here's a little demo I whipped up with just the play head (hover-glow, dragging, and animation).
Re: In defense of <canvas>
#54So, all these tip's I've seen focus on improving canvas performance by somehow splitting the drawing into small pieces .. but what if one is working on a drawing app that absolutely needs to redraw a large area most of the time, think sizes like 800x600 or 1024x768.
Any good tips to optimize this kind of use-case ? I am developing an online Geometry Generator (http://GeoKone.NET) that uses a large canvas that is redrawing complex geometry, with paths that almost always change completely when being modified, thus invalidating the "render to image" option almost in all cases, except maybe when moving the formations around.
Good tips though and nice to read about people's experience. Too bad I am using Processing.js so I am kinda stuck with the optimizations Processing.js is using.
Re: In defense of <canvas>
#55So, all these tip's I've seen focus on improving canvas performance by somehow splitting the drawing into small pieces .. but what if one is working on a drawing app that absolutely needs to redraw a large area most of the time, think sizes like 800x600 or 1024x768. Any good tips to optimize this kind of use-case ? I am developing an online Geometry Generator ( http://GeoKone.NET ) that uses a large canvas that is re…
[deleted]
Re: In defense of <canvas>
#56Canvas may need a lot of sweat to get some performance [1] but there is something it does really well. What strikes me is the lovely API. It just great to use it for charts, procedural UIs, etc... and it also somewhat work with games.
Re: In defense of <canvas>
#57canvas is incredibly fast. I think its 100% capable for anythign except 3d games.
You do realize that you can get a 2D and a 3D context from a canvas element, right?
yes, but WebGL seems to be a better solution for 3d. It actually renders into a canvas element, but its does enjoy the same cross-browser support that canvas currently has.
Re: In defense of <canvas>
#58Should you be using canvas directly? I'm currently writing my 3rd HTML based game, and I'm so tired of using jQuery and DOM directly, so I want to replace it with canvas. Game is a turn-based strategy, so performance is not an issue (there will be some animations, but rare). I looked at the canvas and then at a lot of 2D libraries that can speed the development and prevent me from reinventing the wheel. I'm overwhelm…
If you want a scene graph, have you evaluated fabric.js? It's a popular canvas library, providing mouse events, and import/export to SVG.
Caveat worth keeping in mind, since you mention SVG, is that Fabric is still rather picky about the SVG it handles. I was playing around with it for some very simple SVG symbols that rendered fine using built in SVG support in both Chrome, Firefox and rendered to PNG via rsvg, and loaded fine in Inkscape, and had to manually tweak the svg quite a bit before Fabric would handle it. (I don't remember the exact problem, but think it was an issue with stacking transformations including "translate"). I'm sure that will improve over time, but it was a bit of a nuisance.
Other than that, it seems to work great.
Re: In defense of <canvas>
#59The only thing slow about Canvas I've found is when the canvas area needs to be resized : i.e. canvas.height or canvas.width changes. Drawing itself hasnt been an issue for me.
Try changing fonts often on Firefox. That's ludicrously slow. To the point where anyone doing lots of text on a canvas that might need to support Firefox will need to take special measures to get decent performance (caching, lots of caching, and ordering updates to minimize font changes)
Re: In defense of <canvas>
#60Canvas may need a lot of sweat to get some performance [1] but there is something it does really well. What strikes me is the lovely API. It just great to use it for charts, procedural UIs, etc... and it also somewhat work with games. [1] http://www.gamesfrommars.fr/demojsv2
Really? I thought the API was pretty silly compared to for example Flash Drawing API. Why doesn't it have circle(x,y,radius) for example?