It sounds like you are confirming your goal is to diverge from what real browsers do. This then confirms our decision to drop support for Canvas+. We are not prepared to support something which pretends to be a browser, but in reality is incompatible with what browsers do. Your proposed improvements are simply very difficult compatibility problems for us.
The proposed improvements (apart from the dispose method) are not Canvas+ specific and wouldn’t entail compatibility problems or a new code base. Dropping object references, texture-packing or WebGL texture compression will benefit any browser, whether it’s real or not.
Divergence from real browsers is not the goal behind Canvas+ design. Performance and portability (ex. wearables) are our goal. We created a specialized gaming environment compatible with standard Canvas2D/WebGL APIs. It’s true that some engines required compatibility changes to work with Canvas+, but as explained in the first post creating a browser from scratch is complex and required changes are fewer each version. Default C2 HTML5 exporter works in Canvas+ indeed.
We want Canvas+ to work with any Canvas2D/WebGL engine, ideally with 0 changes. We also offer some non standard features. However don’t think of them as diverging from what browsers do but as optional performance/memory extensions. Features like screencanvas are optional to use extensions. It’s analogous to what happens with WebGL extensions. If a GPU offers a unique extension, you shouldn’t think that it’s diverging from what a real GPUs does and that you’ll never implement that extension in your engine.
While mobile browsers perhaps used to be terrible for gaming, modern mobile browsers are very good and in my opinion very well designed for gaming. The philosophy that "mobile browsers are not suitable for gaming" is in my opinion now out of date and no longer relevant on today's web, and should not be used as a reason to implement things differently. I could go further in to the details of browser caching and memory eviction heuristics, but I don't see much point - so long as your goals are to deliberately go in a different direction, then I neither want the support burden of having to deal with those differences, nor to become embroiled in technical debates about which is the "right" way.
We agree that modern mobile browsers are more suitable for gaming now. In the last post we explicitly said that Android 4.4 and iOS 7.0+ webviews are capable of getting native-feel like games. We also support webviews in the CocoonJS Launcher and any user can compile games using a webview instead of Canvas+ in our cloud compiler. We are not webview haters. We let the users choose the environment that works better for them.
We're going to keep going the way we are which is to design an engine based on a single codebase that runs well in all real browsers.
That's ok. We don't want to change your design decisions. We just wanted to publicly clarify the memory management misunderstandings because we think that our team didn't deserve some of the comments found in the forum. And also, please, recall that we never intended that Construct2 had two different export branches, it was an internal decision and we have been trying to reorient it so the final result (ZIP file) could also be compatible/executable inside a desktop browser.
A lot of users are still using C2 engine with Canvas+. We want the best C2-Canvas+ integration for them. We have released a new plugin for them with upgraded social, box2d and multiplayer services.
The current lazy loading implementation is working (we have even added the idtkLoadDisposed property for backward compatibility purposes), but some users prefer the old way to avoid pauses between layouts without a loading screen. We’ll add a lazyLoading check into the C2 plugin. We’d really like to solve the lazyLoading progress bar issue but it seems to be in C2 side. If we can do anything in our side to fix it, we’ll do it.