Is this a better approach to Layout Performance?

LayOut Feature Requests
1

Find the flaws in my reasoning here please, I cannot get it out of my head that there must be a better way for Layout skp imports:

  • So if the 1 core you use in Layout is beach-balling, while your other 5+ cores are lazily drifting about with nothing to do:

Then Layout should look for help from an idle cpu core:

  • To always know of .skp changes.
  • To get only the updates it needs to stay current.

A new background software, a “Layout viewport service”, could:

  • Run on a free cpu core, if present. Only run whenever sketchup is running and that file is placed in a open Layout file.

  • Read the .skp file from RAM, to know what’s happening in that file at any time, also before skp saves.

  • Maybe also flatten every scene that has been placed in a Layout document, retaining grouping and tags, to keep a real time updated flat version of scenes. That flat scene should be much lighter than the skp. model.

  • The service also collects viewport info, to know what changes to prepare for each viewport.

  • Send changes to Layout viewports, and only the changes, and only to viewports that has changes to them.

  • Layout then swaps just the changed geometry for each scene, and not the whole .skp model, and not for viewports with no change.

  • Make change packages ready for Layout even if its not open, cause it knows that there is a Layout file that would want those viewport changes to be ready for it when opened

Resulting in:

  • Layout could get really small incremental data imports.
  • Layouts general tool performance would not be stressed from having large files purged and reimported.
  • With this strategy one could have Layout presenting live changes, without the beachballs.

Layout by “laws of nature” has to struggle, having large embedded files to process all at once.

Incremental optimizations to Layout code can not possibly solve that main pickle of the large files that needs replacing. So maybe dont put those large files in there in the first place. Most importantly, if you move just one face inside just one group in sketchup, Layout has to purge and reimport that whole file. That just seems to me to be a tad absurd.

Layout , if open and in use, also could make use of other idle user time, so it can prioritise what updates to accept when. First, the updates to the current page, and when it can, prepare the other pages before the user visits them.

1 Like
2

Interesting idea Odd_ …
Have you bumped this by @Adam (LayOut team leader)?
I’d love to know if this is even possible, let alone feasible … it would be great (an oh so efficient) to utilize all those “idle cores” out there!

1 Like
3

@Adam Come to think of it, I see no particular logical reason why such an external viewport engine could not be multithreaded. Each viewport extracts and prepares separate geometry, so that should logically be separate parallel processes.

4

I am a daily user of Archicad. They claim having split the rendering of their different view tabs to different threads. It might be but in practice I don’t think the user experience changed in any way. To be worth the effort the improvement must be real.

5

Thank you for your feature request!

Unfortunately something like this wouldn’t end up working out in practice due to some technical reasons regarding how SketchUp files work. I won’t go into much detail beyond saying that for each skp model viewport that exists in your LayOut file, you would need to have an instance of that skp model loaded in order to avoid problems. This very quickly consumes memory to the point where you would need 32GB+ in order to work on a single LayOut document. Suffice it to say that we wouldn’t proceed with a solution like that that because a majority of users do not have that much memory available on their machines at this time.

Please know that we are working on ways to improve this aspect of LayOut performance (potentially with the ability to parallelize rerendering of skp model viewports).

Thanks for your input,
Adam

1 Like
6

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.