search

nanos-world / issues

Issue Tracker for nanos world
9 stars 1 forks source link

Separate WebUI Thread and Client Thread #504

Closed DKFN closed 2 years ago

DKFN commented 2 years ago

Is your feature request related to a problem? Please describe.

When Ultralight is slow on rendering a browser tick, the whole game Client freezes. This is not ideal because if the UI freeze for 500ms it is not very bad in itself, the problem is that it will also impact the player's client. Especially because Ultralight does a very bad job at preloading/caching images from CSS even if specified inside the HTML Dom, aside from having poor performance at loading and rendering images (5 more time than Chrome, considering Chrome does take 100ms on first paint but will take approx 10ms to render on next UI paint when showing/hiding the divs that contains the images).

Considering the limitations of Ultralight discussed in anorther issue, we have no choice than to rely on Background images to get the GUI we desire.

Describe the solution you'd like

The best solution I could think of is to separate both threads, as the API is already async I think (but I don't know) it should be quite fast to achieve without breaking changes into the API.

Describe alternatives you've considered

There is no real way around it, I downscalled all the images and managed to reduce the rendering time from 500ms to 120ms but this is far from ideal still.

Additional context

gtnardy commented 2 years ago

Thank you for the suggestion, this is really an issue and will be looked on.

I don't want this lag and stutters to be a concern of scripters.

Timmy-the-nobody commented 2 years ago

That would be really cool :) This gif illustrates this issue quite well

gtnardy commented 2 years ago

In the last update from Ultralight, Adam added a new feature of max_update_time, which promises delaying calculation if any tick takes too long, which should help on the stutters (the separate thread is still important though, but this can give us a breather)

Let me know if you see any difference, currently it's set to 10ms, which means if any Render:Update operation takes more than 10ms, it will be rescheduled, I could reduce it even more

DKFN commented 2 years ago

Sorry for the very late reply I missed you reply.

It seems it does help a lot with the lag, when I load a screen that has a fairly big background image to load, I see the content that paints before the background image gets loaded and there does not seem to have much blocking on the client main thread.

That should be more than enough for me right now, thanks :)

gtnardy commented 2 years ago

As it's a feature request, I'm moving it to the new feedback platform: https://feedback.nanos.world/ideas/p/separate-webui-thread-and-client-thread