Netherlands
Joined: Apr 8, 2022
Post Count: 789
Status:
Offline
Re: Linux, slow actions in 2D area.
Weird, anything slow I always experienced in the 3D area, not the 2D area. I know the 2D can get a little slow with many very long walls so I'm going to experiment with your suggestion and see if it helps.
Netherlands
Joined: Apr 8, 2022
Post Count: 789
Status:
Offline
Re: Linux, slow actions in 2D area.
Are you sure that it's the 2D View that is slow? The 3D View updates every time you make a change in the 2D View and usually the 3D View rendering uses more processor power which means more time.
You might want to try the new 7.2 beta version . That is the first version where the 3D View update is halted when you collapse the pane (the small arrows in the pane border) which should prevent the 3D View taking processor power that can be used for the 2D view. When you expand the 3D pane it will render your latest 2D plan without rendering all the steps in between. Especially on slower machines this should speed up things considerably.
Joined: Sep 11, 2023
Post Count: 25
Status:
Offline
Re: Linux, slow actions in 2D area.
Maybe it is the 3D view that slows down the 2D view, but the name of the parameter I added talks about java2d.
So, I think the problem comes from the default 2D renderer that seems to be slower than opengl, at least on my linux system, with this low power computer.
Germany
Joined: Jan 6, 2024
Post Count: 27
Status:
Offline
Re: Linux, slow actions in 2D area.
I have the same experience. I don't have an exact way to produce it. I feel that saving with "Save as..." and loading with "Open recent home..." might be a reason. I'm closing all unused instances so only one is open. Also I have seen that the java process needs more and more memory. Starting with no home it is 180 MB, with the first home it is about 500 MB, with the second it is 680 MB, opening the first one again I'm at 900 MB.
----------------------------------------
MSI GP60, Linux Mint 21.3 Virginia base: Ubuntu 22.04 jammy, SH3D 7.2 with Photo-video rendering 2.8
Netherlands
Joined: Apr 8, 2022
Post Count: 789
Status:
Offline
Re: Linux, slow actions in 2D area.
How much memory is used only has partially influence on speed, mainly you should have enough. As mentioned in previous posts in this thread you can increase the allowed memory use with the -Xmx parameter in the startup script, for example -Xmx4g. What makes a lot more difference in the slowness of the 2Dview is what you have in your project.
Example on Debian with -Xmx6g set: I just started a new project that so far only has walls and a few dimension lines, no other furniture: a whopping 151.1kB on disk. And it uses 5.3GB memory! Why? First I allowed max 6GB memory use and Java WILL use it when given (of course). Second, there are many very long walls and I know that causes slowness. If I shorten every wall to one-tenth it's size it becomes considerably faster. That is just an example, different furniture results in different rendering times in both the 2D and 3D views. Just giving more and more memory will not solve that. On the other hand, allowing not enough memory will possibly cause heavy swapping and the garbage collector will kick in many times more than with more memory (the garbage collector frees memory that is no longer used, with less memory to work with this has to happen more often).
Some options that might help speed up things: Make levels that you don't need for the current task invisible. Close the 3Dview when don't need it (the tiny arrow on the splitter between the 2D and 3D panes). The 3Dview rendering uses the processor, not the GPU. In some cases it it's beneficial to place part of a level on a separate level with the same elevation so you can make that part invisible. Invisible = not having to draw it. In your preferences you can set Furniture icons in plan to Catalog icon or Top view. Usually the Catalog icons setting works faster.
Mind you, these are tricks you shouldn't normally need and it highly depends on your project which tricks have any effect. I work a lot with very large (in meters) projects and have learned what (sometimes) works.
