-
Notifications
You must be signed in to change notification settings - Fork 70
MobileTundraPlan Evaluation
Evaluating the Mobile Tundra project plan
Two ways to evaluate: A. the plan in itself B. comparison with alternative plans. This are discussed below. But first, a couple of requirements from the association board so far:
- Requirements ===============
From a discussion with Francois Garnier / Spinningwire -- content compatibility: Want no return to the stone age. Content compatibility includes not only the visual assets, but also scripts. Earlier, the backwards compatibility breaking transition from Tundra1 to Tundra2 was close to a disaster -- all the apps that had been just developed, stopped working (meeting tools in Majbacka etc. -- I suppose when Admino hosting switched from 1 to 2) (also, IIRC we lost that one dev making a MMORPG with Tundra then, she got bored/scared about the platform breaking under her, and switched to Unity3D).
Tommi Hollström / Adminotech on the same note: an upgrade path is needed. (that is: he recognizes that if we e.g. stop using Qt for GUI, the old codes can't just work, but it should be clear then how to get them back).
Seems viable, a solid plan.
Requires a lot of work for getting even the basics working.
The (earlier) talk about a single codebase is a bit misleading, as with this plan we would end up with two codebases: Tundra (with Qt and Ogre) and Mobile Tundra (without Qt and Ogre). Would we then need to develop and maintain those separately forever, for example when a new EC is added?
Ogre is known to work on iOS and Android -- what about just running it there for Tundra too? This would leave out WebGL. But might give a single codebase for desktop&laptop + mobiles, and with comparatively little work (just build Tundra on Android and iOS and be happy?)
When targeting WebGL only, there are several good open source engines out there already. Three.js seems to be winning, and that is used in current realXtend efforts as well.
This has brought up the question: what about just using WebGL only? Cloudparty and TinkerCAD are going with that strategy.
Earlier (spring 2012) WebGL was deemed unsuitable on mobiles, based on how slow it was then (on Opera on some Android tablet, right?). Reportedly, this is just because the WebGL implementations have not been mature yet on mobile platforms -- Chiru says that there is no fundamental reason why it would be slow.
OTOH WebGL / js rendering engine performance is slow on desktops / laptops too compared to mobiles. How much and quickly is the JITting improving?
What is the expected perf on diff devices in e.g. spring 2013?
What about optimizing the good/popular WebGL engine, Three.js, by implementing it's renderer for native execution? For mobile apps, NaCl in Chrome, and installable apps for desktop/laptops too. Would it go nicely on top of GfxApi? Is Three's API really so good that we'd like to go with it? (how does it compare/relate with the reX EC model?)
This way we could already develop apps on three for webgl use, and later they would run faster / with less energy consumption too?