Stretching objects with 3D hotspots couses freeze

[kristoftihanyi]

Hi!
Lately I have been having issues with  vertically stretching library parts using their hotspots in 3D view.  The operation causes the program to freeze up for about 20 seconds. This happens with library parts like chimneys and kitchen cabinets, so I'm guessing it has to do with complex, parameter driven geometries. Is this a known issue? Can we expect it being fixed soon?

Operating system used: Windows 10

[Lingwisyer]

Hm... so it is specifically the height stretch function rather than modification and feedback of the ZZYZX parameter... If it is consistently buggy for you with the height stretch, would you be able to do a test and rotate your objects axis and see if and which axis has an issue? So like add a ROTx 90 to the start of the script.

Ling.

[Barry Kelly]

---

@Lingwisyer wrote:

If it is consistently buggy for you with the height stretch, would you be able to do a test and rotate your objects axis and see if and which axis has an issue? So like add a ROTx 90 to the start of the script.

---

Unfortunately, the standard hotspots lose the move node and stretch height options in the pet palette.

The moveable hotspots still stretch OK.

Barry

[JL2004]

Following your post, thought I'd run through our libraries (curious as no-one from our teams have mentioned any 3D stretching issues)... and can't find any instance where moving node and/or stretching object causes any issues. So I spot checked a load of GS objects too... aside the kitchen cabinet... can't find problems with any other component either.

Did you base your cabinet originally off the GS object or create from scratch?

I wonder what is specific to those objects that's causing the issue... 🤔

[Barry Kelly]

I thought it was only the 28 kitchen cabinets also, as I had tried other Archicad library objects with no problem.

Which is why I have complained loudly about those cabinets.

My cabinet object is based on a default Archicad library object, but that was back in version 6.5

So it has no similarity with present day objects.

I am wondering (but I haven't tested yet) if it is something to do with 'ac_bottomlevel' and 'ac_toplevel', as I have never really bothered using or setting these in my objects.

I am wondering if there needs to be a relationship between those and the actual object height.

Barry.

[Paul King]

As a test, I set  Windows Resource Monitor running, and I could then see the second I start selecting and stretching anything in ArchiCAD, the system SSD hard disk activity abruptly jumps up to 100% capacity, and stays there for as long as the element remains selected and I keep moving the mouse around (forcing the selected object to keep recalculating its geometry on screen).  

SSD drives - even good ones, are nowhere as fast as RAM, so this is a problem.

CPU activity also jumps up to 100% even though very little seems to need recalculating.

If, under the work environment menu, I switch data safety down from my normal ‘save every step’, to ‘save every 5 minutes’, the disk writing overload no longer occurs while the object is still being adjusted, and lag reduces, although does not disappear, with the CPU activity remaining saturated at 100% for far longer than it should.

From this, it seems that ArchiCAD is treating selected objects that are thus undergoing dynamic feedback as a series of thousands of actual edits or changes per minute to the database, rather than representing changes as a purely temporary visual approximation, so with data safety set to maximum, it is trying to both recalculate the geometry of the object (and presumably everything it interacts with), and physically write the dynamically changing state of the object thousands of times a minute to the local disk cache, even before the edit is actually finalised.

While this is happening, there is always plenty of free ram – and GPU activity is also very low – so this seems to rule out these things as system bottlenecks underlying the problem.

I wonder if at least part of the lagging problem might be resolved by the developers fixing their code so that it does not tell ArchiCAD to write the changing geometry to disk cache while the editing / dynamic feedback phase is still active when data safety is set to Ultra, before the edit has actually been finalised with a mouse click.

The CPU overloading during dynamic feedback on even simple items with stretchy hotspots may need another solution.

Possibly related is that the mere act of zooming in and out in plan saturates the CPU, suggesting that perhaps hardware acceleration is not working at all under Direct3D, even though it shown set to maximum in options (although this setting is greyed out, so no user adjustment is possible).

[Barry Kelly]

Interesting observations, but I am not sure if this is the cause.

Seems to be only objects (not other elements).

If I stretch object height with a moveable hotspot, it works fine, just not with the height stretch.

Surely it would be doing the same calculations in both cases.

Which also rules out my top/bottom level theory.

I tried changing the 'ultra safe' recovery, but didn't notice any difference.

Barry.

[Paul King]

I can also confirm significant lagging also occurs for me using height stretch for many objects in 3D views.

In my testing above, I was using dynamic hotspots to stretch a slightly complex object purely in plan view, rather than height.  Not all objects generate the same amount of lag for me, whether using height stretch or dynamic hotpots to change the geometry. 

[Paul King]

OK, with more testing I have discovered a crude and unpleasant workaround.

Whether doing vertical height stretch in 3D window, or adjust affected objects via stretchy hotspots in plan view, if you move your mouse pointer out of the ArchiCAD window for a couple of seconds, then move it back, the object will have completed its adjustment.

It seems to be that while the pointer is in the ArchiCAD window, dynamic feedback is active, which seems to make ArchiCAD unresponsive for certain objects (seemingly unrelated to complexity).

When the pointer is moved outside the ArchiCAD window, the dynamic feedback system can cease its operation, allowing the object to simply adjust to the most recently clicked point without further delay.

[Paul King]

OK, some more testing, and I discovered two things

The first one is that killing a Windows process called 'CefSharp.Process' makes a huge difference to the stretchy hotspot dragging dynamic feedback lag problem in ArchiCAD.

This process is associated with Chrome based browsers, and seems to be scheduled to automatically run on Windows startup (they are present even if no browser is opened manually ) - guessing they are there to monitor for browser security / software updates.  You may have several showing in TaskManager on startup if you have several Chrome based browser apps installed.

If you kill just the first one of these processes, even if Task Manager does not show it to be particularly active, suddenly dynamic feedback for the affected objects works again for me.

This is for the plan view hotspot stretching lag issues (which so far only seems to affect a few objects, and only in ArchiCAD 28)

For the 3D height stretching lag, terminating a few more instances seemed to help - though some cannot be terminated.  Possibly a permissions issue.

The only way may be to disable the automatic check for updates on windows start-up in browser settings - which they recommend against for security reasons.

If even after closing as many instances as possible, you later open a browser or add more browser tabs , you may need to go back and kill the new  'CefSharp.Process' tasks you created.

The other thing I discovered with the dynamic feedback lag for both plan view and height stretching in 3D - if you move the mouse pointer out of the ArchiCAD window and back in a second later, the dynamic feedback freeze immediately ends, the screen refreshes, and you can see the results of your edit straight away.

*** EDIT 30/7/25 *** 

I have traced the source of ALL the instances of the CefSharp.Process running on my system to ArchiCAD itself! (Task Manager/Open File Location on every running instance points to ArchiCAD install directory;    "C:\Program Files\Graphisoft\Archicad 28\GSCEF\CefSharp.BrowserSubprocess.exe").

Possibly it relates to ArchiCAD's browser based help system wrapper that invokes the browser window, rather than the browsers themselves?

I wonder if this is a wait chain issue?  Might explain why the CefSharp.Process itself reports little or no activity during the dynamic feedback freezes, even while ArchiCAD’s CPU activity remains ongoing while everything is frozen on screen - ArchiCAD or its graphical subsystems might be constantly checking if to see if some condition created by CefSharp.Process has been cleared yet.

Changing all my installed browser's settings to prevent the running of browser background tasks, updating in background, hardware acceleration etc made no difference to lag when tested – What I can see is that the CefSharp.Processes are not now present on windows startup, but multiple instances still appear anyway when I start ArchiCAD.

This does definitely look a lot like an ArchiCAD problem to me 

*** 

I hope GS are monitoring this and investigate both of these clues!

.