mcpiroman
commented
3 years ago To OP (@GenuineAster):
Interesting thread as I'm in somewhat similar situation technical-wise. I plan to build the whole 2D game in the web land, but because of lower level stuff I'd prefer, or have to, use ultralight, instead of e.g. ElectronJS. Also, I don't use React but self crafted, very lightweight framework (base on fritz2) to do only necessary DOM updates, with minimal JS (though, I don't need any pre-built components whatsoever). It also integrates well with server side. So, performance are in the top of my biggest concerns here. I started with chrome and they seem to be kinda whacky for a basic structures, but I hope that will scale in a convex manner, and, with feature optimizations here and there (potentially WASM), will be acceptable. But as you mentioned there is a 20ms to 7ms gap between chrome and ultralight, I begin to worry even more. Also, how often the 20ms thing happens: initialization, rerender of single property, per frame?
(My background: I started with quite low-level, OpenGl-based framework (libgdx), but I want to migrate because:
- I'm sick of doing all the layout calculations, shape drawing and all the low-level stuff myself, whereas this could be easily done with a little bit of html markup.
- The view is rather static for a game, so the philosophy of rerendering altered parts rather than clear-draw loop seems more appropriate here
- I want extensibility for modding, html and js seems much better for that than jvm.
- What year is it?
)
To maintainers (@adamjs ?):
I'd like to kindly ask a more general question: how, from your side of knowledge, the ultralight is, and how is it going to be in terms of performance compared to major web browsers. Are there any major, long-statning reasons for it to be slower or faster in given regard? For js relates to #304, but e.g. maybe web-kit is just known to be slower than blink (render engine of chrome) and we can do nothing about it?
GenuineAster
adamjs
yamaken93
Are there any resources on performance optimization for Ultralight?
This is a bit of a long one, I tried to include our user story so the case would be clearer and if my approach is bad, someone could tell me. We are basically prototyping Ultralight replacing our in-house GUI framework. We are a product in development, no revenue yet, but we of course are looking at a commercial license if this integration is successful.
I had the grand idea of replacing our in-house GUI framework (which is missing expensive features to develop like animations, drop shadows, stateful inputs, etc.) with something like JSX/ReactJS and HTML5. The vision was that we could get our UI/UX designers to take a course in insert-high-level-markup-lang-here and then they could solo-fly the GUI and we could save lots of iteration time and give everyone involved more freedom.
I found Ultralight as an obvious framework for integrating that into our game engine, and embarked on my moonlit journey of prototyping this integration. I picked a more technically complex part of our GUI to try to "replace" to see how hard the integration would be in the worst case, and get a feel for the overall complexity of maintenance & development for my team. Rendering went great, plan to implement GPU renderer but the CPU one hasn't given me too much trouble yet for our (relatively) simple UI. Then I had to wrap my head around calling C++ from JS so we could get the relevant data in, wrote a small library for helping with bindings and now it's pretty straightforward.
Then, I got to work on my React prototype. I prototyped in the browser, and eventually got everything functionally working. I moved over to in-engine, and "rendering" (i.e React creating DOM elements for everything) my 5-ish accordions and 20-something sliders in React (with Material UI) takes a whopping 50ms! Not a frame spike I'm happy with. This plunged me into the world of optimizing JavaScript for a couple days (which, by the way, is nowhere near my high, C++ standards). I enabled a few fancy build flags, virtualized my accordions, and tried again. 20ms! I've never been so unhappy with a >2x performance gain.
Profiling this in Chrome puts it at just 7ms, not a great number but way better than in-engine. (An explanation for that one would be great, I'm just boiling it down to different JS engines and potentially JIT being disabled? But I understand that's only on consoles.)
Worth mentioning that I'm looking at the time taken in either the MouseEvent handler or when running a JS callback (or onClick in Chrome) which all do the same thing: causing most of the content to be re-"rendered". I have profiling zones in our C++ code to make sure we're not what's slow. Here's an image of what that looks like in our profiler:
Okay, React is probably just slow. As I understand it, it's actually material-ui that's slow but I'm not sure we can make our own component library much faster if we want things like touch ripples and animated accordions.
I looked at other options, there are a few constraints here:
I'm not a web developer, so I'm not expert in these things, but I went with Angular and Material again, hoping that web-components would save me. 7ms in Chrome and.. 21ms in-engine.
I'm not really sure how to do this better at this point. I guess in Chrome stuff feels smooth because there's no game running behind the GUI that hitches when you click on stuff. I suppose I need to run Ultralight updates on another thread? And that's where I'd like some guidance:
renderer->Render()) takes about 5ms for your curiosity)We are targeting low-end hardware so we don't have infinite cores to dedicate, I think anywhere between 1/4-1/3rd of a core is fine-ish for now, we can have it on the same core as our physics engine.
Any pertinent information is absolutely welcome, thanks!