Live data from Hacker News

Speeding up Unreal Editor launch by not spawning unused tooltips

larstofus.com

61–70 of 92 posts

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#61
post #4

Earlier quoted context omitted.

I remember solving this problem before. These are both global components, so you create a single global instance and control them with a global context or function. You basically have a global part of the component and a local part. The global part is what actually gets rendered when necessary and manages current state, the local part defines what content will be rendered inside the global part for a particular trigg…

React devs re-discovering DOM manipulation... SMH. This is, in general, the idea that is being solved by native interaction with the DOM. It stores the graphic, so it doesn't have to be re-instated every time. Gets hidden with "display:none" or something. When it needs to display something, just the content gets swapped and the object gets 'unhidden'. Good luck.

The post you’re replying to is saying they went FROM always having the component mounted (at least in the component tree if not in the DOM as display:hidden), TO only mounting the component when it needs to be open. They moved from the way you’re talking about, to creating the component/DOM nodes only when needed.

Excessive nodes - hidden or not - cost memory. On midrange Android it’s scarce and even if you’re not pushing against overall device memory limit, the system is more likely to kill your tab in the background if you’ve got a lot going on.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#62
post #4

Earlier quoted context omitted.

I remember solving this problem before. These are both global components, so you create a single global instance and control them with a global context or function. You basically have a global part of the component and a local part. The global part is what actually gets rendered when necessary and manages current state, the local part defines what content will be rendered inside the global part for a particular trigg…

React devs re-discovering DOM manipulation... SMH. This is, in general, the idea that is being solved by native interaction with the DOM. It stores the graphic, so it doesn't have to be re-instated every time. Gets hidden with "display:none" or something. When it needs to display something, just the content gets swapped and the object gets 'unhidden'. Good luck.

[deleted]

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#63
post #24

From a purely technical perspective, UE is an absolute monster. It's not even remotely in the same league as Unity, Godot, etc. when it comes to iteration difficulty and tooling. I struggle with UE over others for any project that doesn't demand an HDRP equivalent and nanometric mesh resolution. Unity isn't exactly a walk in the park either but the iteration speed tends to be much higher if you aren't a AAA wizard wi…

That's extremely unfortunate given that Unity is becoming financially hostile gouging enterprise customers, and apparently Godot is not quite mature enough to compete. Game engines are quickly becoming a problem

> Game engines are quickly becoming a problem

Game engines have always been a problem. They're very tricky to make and cover everyone's use cases, and I don't think they've ever been in as good a state as right now.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#64
post #13

This reminded me, I saw tooltips being a large chunk when I profiled my react app. I should go and check that. Similarly, adding a modal like this {isOpen && } instead of Seems to make the app smoother the more models we had. Rendering the UI (not downloading the code, this is still part of the bundle) only when you need it seems to be a low hanging fruit for optimizing performance.

That breaks the out transition.

Good point, luckily there are no transitions for modals in this project.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#65
post #24

From a purely technical perspective, UE is an absolute monster. It's not even remotely in the same league as Unity, Godot, etc. when it comes to iteration difficulty and tooling. I struggle with UE over others for any project that doesn't demand an HDRP equivalent and nanometric mesh resolution. Unity isn't exactly a walk in the park either but the iteration speed tends to be much higher if you aren't a AAA wizard wi…

My issue with Unreal is that Epic puts little effort into improving the developer experience, focusing instead on churning out tech demos, flashy visuals and half baked features that only become usable after several major releases (if ever). The artists at my company love it, the developers not so much.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#66
post #61

Earlier quoted context omitted.

React devs re-discovering DOM manipulation... SMH. This is, in general, the idea that is being solved by native interaction with the DOM. It stores the graphic, so it doesn't have to be re-instated every time. Gets hidden with "display:none" or something. When it needs to display something, just the content gets swapped and the object gets 'unhidden'. Good luck.

The post you’re replying to is saying they went FROM always having the component mounted (at least in the component tree if not in the DOM as display:hidden), TO only mounting the component when it needs to be open. They moved from the way you’re talking about, to creating the component/DOM nodes only when needed. Excessive nodes - hidden or not - cost memory. On midrange Android it’s scarce and even if you’re not pu…

Especially when you know the user won't be opening half of those. I did'nt use a global one because the modals themselves have some complex logic inside.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#67

This reminded me, I saw tooltips being a large chunk when I profiled my react app. I should go and check that. Similarly, adding a modal like this {isOpen && } instead of Seems to make the app smoother the more models we had. Rendering the UI (not downloading the code, this is still part of the bundle) only when you need it seems to be a low hanging fruit for optimizing performance.

Alternatively, how many modals can be open at any given time? And is it a floating element? May be an option to make it a global single instance thing then, set the content when needed. Allows for in/out transitions, too, as another commenter pointed out. See also "Portals" in React.

There is only one. Won't contexts cause rerenders through the tree? We already use portals. It's just each modal have complex logic inside them that they're their own component.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#69
post #48
post #32

Earlier quoted context omitted.

The reputation of being poorly optimized only applies to version 5, UE was rather respected before the wave of terribly performing UE 5 AAA games came out and tanked UE's reputation. It also has a terrible reputation because a bunch of the visual effects have a hard dependency on temporal anti-aliasing, which is a form of AA which typically results in a blurry-looking picture with ghosting as soon as anything is movi…

Funnily enough a lot of those "poor performing" UE games were actually UE4 still, not UE5.

Let's be real. UE5 is a marketing term for a .x version of UE4 that broke a bunch of the rendering pipeline such that they needed am excuse to force devs to deal with the changes.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#70
post #13

This reminded me, I saw tooltips being a large chunk when I profiled my react app. I should go and check that. Similarly, adding a modal like this {isOpen && } instead of Seems to make the app smoother the more models we had. Rendering the UI (not downloading the code, this is still part of the bundle) only when you need it seems to be a low hanging fruit for optimizing performance.

That breaks the out transition.

You should rethink your modal system if removing the controller component from the render tree doesn’t transition out
Post reply on HN