@zhangxm
Hello.
You and cocos engineers are programming master but I have a proposition for you.
If you don’t change any line of rendering code in OpenGL ES at all then all projects is backward compatible, and any custom OpenGL and Shader code in any projects works. (like in my project).
Then write all Metal rendering code from scratch. (Metal written by C++ and very clean if I’m not wrong). I mean rewrite transformation matrix and all rendering stuff for something like sprite. and by preprocessor code we have some sprites creating by Metal or by OpenGL. I know this is very complicated and time consuming. This approach is far from cross platform rendering like bgfx. If you are supporting core Metal API, someone like me can implement some custom Metal code and Metal shader (like OpenGL code in my project). Many of us use cocos because it’s open source and we have full control and can implement our custom code. I like this feature in Metal supported version of cocos (and Vulcan in future).
Best Regards.
Did you mean we should do two things:
- first, use metal to implement OpenGL ES API
- second design a new renderer from scratch
I like this idea, but i don’t think we have enough resource to do these things at the same time.
Hi. @zhangxm
Yes, Design a new METAL renderer from scratch and not change any of OpenGL API in previous version. cocos2d-x renderer is stable enough for OpenGL ES2 and you can stop supporting it (like Apple). Android projects (and Win32) can use it for some years (2 or 3) and the new fresh Metal renderer with all core Metal API support iOS and Mac projects.
And later you can deprecate OpenGL ES and Add new Vulcan Renderer for android (and desktop).
I don’t like cross platform renderer with some level of indirection to do all graphic stuff (like Unity if I’m not wrong) but you are the Boss! 
But if want to support metal, vulkan at the same time in future, then we need some level of indirection too. And if new version of cocos2d-x only supports iOS or Mac, then i think it is not a good idea.
I found google nxt is a good start point. It is designed for webgpu, but i think we have the same goal, working for next graphic API(metal, vulkan).
Why not go with bgfx?
This was something proposed by Ricardo Quesada 2+ years ago.
I think it would have lots of advantages:
-
It supports multiple apis (including Metal).
-
Frees resources from the cocos2d-x team since they won’t have to maintain the rendering backend.
-
It’s open source so eventually, if needed, cocos2d-x team could make any changes it wants to it.
I was thinking about it more even though i was also thinking "why not use bgtx or SDL2 "
this can introduce more problems as it will force the cocos team to modify the rendering engine when problems will appear or wait for fixes in engine that is not their this is sometimes very problematic .
now i think they should add simple interface to the Metal infrastructure as they did with OpenGL
There’s this sokol here that implemented metal rendering… I’ve tried on Mac and it appears to work. Didn’t tried on ios…
He means that we will support metal first, before we tackle others. There isn’t a branch started for this work yet.
don’t feed the troll
Thanks. I really try to remain objective 
I don’t understand why you saying that. I’m just asking about this because it’s very important for my team. It’s very sad, that it’s fun for you.
Sorry dont misinterpret my reply. I said I try and remain objective…meaning I treat every question the same because we have users from all languages and cultures and therefore someone might write something that some take offense to and some don’t. I look past this.
Or Kore … system and rendering API abstraction in one small super portable C++ library. Korecos … mmm 
I just learned about Kore too!
I’ve been experimenting with it FWIW. The graphics API is simple and flexible, and as far as the same code (including shaders) running across iOS, macOS, Win32, UWP, HTML5 is concerned it just works. I used the Kore::Graphics4 API but I should really check out Graphics5 for multithreaded goodness. There’s implementations for everything from RPi to PS4/XB1/Switch.
Interesting. What about performances?
Best I’ve tested, though Kore is a very thin layer over the underlying back-end so the engine you put on top will be the primary factor in performance.
In my BunnyMark tests iPhone 6s gets 38000 with Kore, the batcher class from the linked repository and the OpenGL back end. Cocos2D-X gets 6800. Godot 3.0.2 gets 1100. Kore’s built in “Graphics2” simpler sprite API gets 29000.
More comparative figures are here.
There was a problem with the Kore Metal shader compiler at the time so I couldn’t test that.
I am still in researching. The reasons why not choose BGFX are:
- it is huge and complex
- if there is bug in BGFX, then it is hard to solve it
- it is not designed for next generation graphic API
The google’s WebGPU seems good.