Had some time to update boxer, scene graph now sends messages back to window and animates DOMElements. It’s really bare bones right now and looking for help to convert model from Nodes into matrix 3D transforms used by DOMComponents. The only thing famous by now is I hacked away Transitionables to work. Anyone want to help take this prototype to the next level? https://github.com/infamous/boxer
1 Like
Another hour of dev paid off, Boxer Engine now supports CSS 3D transforms.
Some late night coding led to the creation of a new ViewController, which abstracts a lot of common tasks I was starting to use in application logic. I also added support for Transitioning Arrays and the current demo is running at ~35 fps rotating 180 DOMElements at once. View the demo here http://devmagnet.net/boxer/demo/ (Google Chrome supported only for now, but support is possible for Safari, Firefox, IE11 and Edge).
The demo at http://devmagnet.net/boxer/demo/ now has cross browser support for Chrome, Safari, Firefox, and Edge. IE11 in Windows 10 is unverified, but may be supported. Performance is slower in Firefox, Mobile Safari and Edge respectively. Right now there isn’t the concept of an update queue in the project where objects that need to be transformed are added and removed, everything is just running. Anyone have some ideas on how to make this project more performant? https://github.com/infamous/boxer
1 Like
Tested on IE11 and the boxes initially show but do not animate. No console errors.
IE10 doesn’t show any boxes and has the console error:
SCRIPT5007: Unable to set property ‘node’ of undefined or null reference
boxer.js, line 1176 character 5
IE11 support may be possible in Windows 10, but no promises. It all depends on the availability of transform-style: preserve-3d which was not available in IE until the release of Windows 10. IE10 will not be supported, there is no way to use Matrix3d transforms in this browser.
I completely understand supporting modern, capable browsers only. However the reality of the market is that IE10 is still prevalent. Even IE9 is important enough that many businesses mandate support for it. Would it be possible to address these later through polyfills or shims? It’s not something we should focus on right now, but it would help to architect it in such a way to allow for polyfilling.
Unfortunately I do not think Matrix3D transforms can be shimmed. What is happening here is more low level and depends on the browser leveraging the GPU. Maybe I am wrong, I just don’t think its possible. At end of the year Microsoft is sunsetting support IE8 and soon enough IE9. This framework IMHO is not required to work in older variants of IE and should be positioned as a next gen solution. Currently boxer works in Chrome, Safari, iOS Safari, Firefox, and Edge. I think this coverage is good enough for now.
1 Like
Perhaps I should have been more clear. Matrix3d is supported but only 2d is possible and from what I understand no hardware acceleration. Preserve-3d is missing in ie11 and below, and was introduced in Windows 10 IE11 and Edge. It’s useless if the property doesn’t propagate to children.
Have you tried to benchmark a stress test of this approach vs a non-worker approach? I’d be interested to know what the trade offs are in any
Also, my 2 cents, the API may be a little better if instead of defining the ‘transition’ with a key ‘t’ and name ‘opacity’ the ‘transition’ object have a key ‘opacity’ whose value was the other transition properties. Then you could animate several keys at once.
The next step is testing against non-worker approach There are several aspects to the API that definitely need to be refined. What is there was to just get everything working ATM.
@Steveblue is right about not being able to shim CSS transforms. There’s no way we can manipulate the native side of the browser like that with JavaScript. The best we can do for older browsers would be to have a canvas2d renderer, but you won’t be able to put HTML content in there (not without implementing an HTML renderer yourself, inside of the canvas2d context (one such example is html2canvas)). But I don’t think that’s a priority for us. We’re aiming to make a performant library, and there’s not really much point in making this work in a browser where the frame rate will be really really slow and things will be jank. We’ll be able to run this in IE11 using a non-preserve-3d renderer (similar to Three.js’ CSS3D renderer), but that will mean less performance with nothing we can do to improve it, because for each sub-element in the sub-graph of a node that we’re animating we also have to re-calculate all the world transforms for every single child and grand child of the parent node. In modern browsers, preserve-3d prevents us from having to do that, by caching transforms, and world transforms are calculated by the browser on the native side. This prevents us not only from having to do the calculations, but from having to apply string values to the style of each element, which is sloooooow.
So, without a canvas2d renderer, the earliest we can support is IE11. If someone eventually makes a Canvas2D renderer, then we can support down to IE9 for rendering 3D things in canvas2d (but not DOM, and no WebGL). To get a feel for how slow canvas2d would be, try looking at some of the canvas2d demos for Three.js. Here’s one in WebGL, and here’s the same one in Canvas2D. Mrdoob put a ton of effort to get that running in Canvas2d, and the quality is horrible compared to WebGL.
As soon as we have our prototypes working, and have merged into a single project, we’re likely to continue working on features for the latest browsers that have full support of the 3D APIs, and improving the performance in that area. There’s lots of work to do there.
A good question to ask ourselves: “What do I want to make, and which platforms will let me do it?” Then, choose your platform and frameworks for that platform.
One of our goals is Mixed Mode mixing WebGL with DOM. It would be a lot of added overhead to make sure that an implementation of that plays well with code that is meant to support IE 9 and 10. Introducing backwards-compatible code to support incapable browsers would be a high potential for bugs and a high cost of maintenance. It just doesn’t seem like an efficient idea for the goals that we have with the library (and the awesome things we want to make with it).
TLDR: someone in the community who wants support for older browsers would have to step in and take on the challenge of the canvas2d renderer (and/or a transform2d fallback renderer that works seamlessly with the 3D APIs that we’re making).
Falling back to 2d transforms should be relatively straightforward. Set z to 0 and use the 2D CSS API instead of a matrix transform. Devs that want to support ie9/10 should do so with the restriction that their app is 2D.
You’re preaching to the choir, @joe 
I’d much rather target modern, non-crappy browsers too, but this boils down to business decisions and not solely technical merits. I imagine everyone here wants this to become successful, and a big metric of success is adoption rate. Businesses are allergic to technologies that are unable to service a significant percentage of their users.
A low performance solution, even 2D-only as suggested by @dmvaldman, would be sufficient. It would alleviate the need for devs to create two separate sites, one for capable browsers, one for older ones. Users of older browsers can suffer through the low performance, or upgrade. It’s better than a blank page,
Another way of putting this: without IE9/10 support, I won’t be able to use this in any commercial projects. It’ll be relegated to hobby side projects for the forseeable future. Maybe that’s where you want this to be, and that’s ok, but it’s worth putting a stake in the ground one way or the other so that people will have the appropriate expectations.
1 Like
This is an very important statement from a user perspective everyone here who is working on an engine should keep in mind.
Don’t get me wrong, I really appreciate what you guys are doing, but for me, any engine that doesn’t support webview’s on iOS and Android is of no interest.
I got drawn to Famo.us because it promised 60 fps on mobile and since I’m using Cordova/Famo.us v0.3.x/BackboneJS for mobile app development with performance close to native.
Does any of the engines in work has a focus on mobile first?
I don’t think this solution is practical. It isn’t just positioning that is effected but anything requiring perspective. It sounds like a simple solution to just forget about Z, but what if the required transition is a flip that requires rotation? We then have to provide a way to specify two different transitions for a single component? It isn’t a question of low or high performance, IE10 and below will require a completely different implementation IMHO.
@bardu the Boxer Engine demo works in Mobile Safari, haven’t checked the default browser on Android but it should work in Chrome. I think there will be a limit to number of Elements that can be transitioned at once or possibly performance gains from not animating elements outside the viewport, because right now perf is kinda slow compared to desktop browsers. But then again, nothing has been optimized for performance at this point. I agree, whatever solution we come up with must work in Mobile browsers, but here we will also run up against a wall with older versions of Android that don’t support requestAnimationFrame for instance.
@Steveblue just to clarify, I’m talking about webview’s which are not the same as mobile browsers. For devs who are working on hybrid apps with Phonegap/Cordova there is crosswalk that provides modern web technologies even on older versions of Android.