CutJS – Fast 2D HTML5 rendering engine for game development • Hacker News Board

Re: CutJS – Fast 2D HTML5 rendering engine for game development

#51

Post by pjmlp » Tue, May 06, 2014, 1:42 PM UTC

kevingadd wrote: post #44

pjmlp wrote: post #19

Earlier quoted context omitted.

Most likely because they also want to target mobile and system browsers don't allow for it.

Note that most canvas implementations on mobile are not hardware accelerated, so you're not getting all that much for your trouble. ;/ WebGL on mobile performs much better than Canvas on mobile for configurations that support both, just like on desktops.

Which configurations?

WebGL is forbiden on iOS other than iAds.

Most Android devices don't support WebGL on their system browsers, requiring the users to install Chrome or FireFox. Even then, some devices have their drivers blacklisted.

WP only supports partially hardware accelerated WebGL in some devices with IE 11 mobile.

Re: CutJS – Fast 2D HTML5 rendering engine for game development

#52

Post by shakiba » Tue, May 06, 2014, 2:05 PM UTC

kevingadd wrote: post #42

'Fast' is a poor descriptive choice for a library that was clearly written without attention paid to CPU performance characteristics, GPU performance characteristics, or the nature of modern Canvas implementations. EDIT: A quick glance at the sample game 'O!' in the chrome profiler shows that it is triggering a garbage collection roughly every second. Pretty bad for a game with such low scene complexity and rendering…

Regarding you technical points:

Yes, there is an issue with O!, it makes too much garbage, it should be corrected.

I guess your point is to store depth of a drawable instead of traversing the tree? I'm not sure how faster it can make the entire rendering process.

tick(fn) to register fn is only called during initializations (not every frame), it doesn't matter how it is implemented.

Instead of pin({}) you can use pin('name', value) or simply reuse your {} object. I don't see any problem with "_next = {}" where it is used for creating tweening.

Without type hinting it is still fast enough, but good idea.

Thanks for your point about "throw", however I'm not sure functions having "throw" really need to be optimized, but I will consider that.

absoluteMatrix is only for internal use, and I have not documented it yet, but it is what it is and is only updated on ticks for performance reasons.

Thanks for your point about drawImage try/catch.

I'm not sure how drawImage with source params is optimized across different platforms so for now I have let it be as it is. But I agree with your point.

There is obviously a lot to make it run faster but the point is to find bottlenecks which really matter. For example in most case the bottleneck is the physics engine not rendering engine at all.

Also if you notice you can see I have done a lot to make it fast, for example using lots of timestamps (ts) and monitors (mo) to avoid unnecessary calculations.

Anyway feel free to fork it and change anything to prove that I'm wrong! I will appreciate that!

Re: CutJS – Fast 2D HTML5 rendering engine for game development

#53

Post by dikei » Tue, May 06, 2014, 2:37 PM UTC

Kiro wrote: post #31

dikei wrote: post #27

Yet another canvas manipulation library, just like fabricjs, kineticjs and easeljs

What's your point? Also, this looks like a new approach.

I don't think this approach is new. Scene graph structure has been used for a long time, and those libraries also make use of scene graph or allow you to use it.

Re: CutJS – Fast 2D HTML5 rendering engine for game development

#54

Post by shakiba » Wed, May 07, 2014, 5:21 AM UTC

shakiba wrote: post #52

kevingadd wrote: post #42

'Fast' is a poor descriptive choice for a library that was clearly written without attention paid to CPU performance characteristics, GPU performance characteristics, or the nature of modern Canvas implementations. EDIT: A quick glance at the sample game 'O!' in the chrome profiler shows that it is triggering a garbage collection roughly every second. Pretty bad for a game with such low scene complexity and rendering…

Regarding you technical points: Yes, there is an issue with O!, it makes too much garbage, it should be corrected. I guess your point is to store depth of a drawable instead of traversing the tree? I'm not sure how faster it can make the entire rendering process. tick(fn) to register fn is only called during initializations (not every frame), it doesn't matter how it is implemented. Instead of pin({}) you can use pin…

I compared O! GC with few other HTML5 games, it seems that GC frequency is normal with high number of game objects.