+- Wings 3D Development Forum (https://www.wings3d.com/forum)
+-- Forum: Wings 3D (https://www.wings3d.com/forum/forumdisplay.php?fid=1)
+--- Forum: Bug Reports (https://www.wings3d.com/forum/forumdisplay.php?fid=12)
+--- Thread: Why does the GUI block? (/showthread.php?tid=2408)
Why does the GUI block? - tangent - 02-16-2017
I was hoping to use Wings as a demonstration that you can have a GUI app that does not block when it's busy doing something heavy in the background without using low-level OS threads directly, but my attempt to produce a demonstration case failed horribly. (That is, I wanted to prove the value of Erlang-style concurrency vs. traditional "GUI thread" style concurrency.)
Steps to reproduce:
- Create a cube in a new scene
- Rubber-band select the cube
- Press "S" five times to make lots o' polys
- Right-click, Bevel
- Try to do something with the menus while it munches on step 4
This test was with Wings 3D 2.1.5 freshly-installed onto a late 2012 iMac running macOS 10.12.3, then repeated in a Windows 10 VM under VMware Fusion on the same hardware.
I don't know if the fact that the bevel step takes many minutes is also a bug. I didn't expect to be able to bog it down so easily. (6,144 polys!)
RE: Why does the GUI block? - dgud - 02-17-2017
Wings is currently mostly implemented in one (erlang) process, we are working on that,
so showing erlangs concurrency with wings is not a good idea now and I don't know if ever.
In 2.* we have processes for the non opengl windows and dialogs with preview,
but that is done to make the code easier not making it work concurrently.
But it's hard to make stuff concurrently in gui applications, you can't generally
allow new commands before the previous commands are done anyway, that would most
often confuse the user.
Which is why most dialogs (in any language or OS) are modal/blocking.
And in the bottom there is still one and only one gui thread everything must pass trough.
So in OpenGL which is state driven, you must handle one process at a time, interlacing
OpenGL code from several processes/threads can not be done to the same window.
That said we are working towards one process per object, mainly to ease to garbage collection
for large models, but it will be possible to make commands that operate on several objects do
that in parallel.
Bevel is seriously one of the most complex commands that there is in wings :-)
so I'm not surprised it takes a long time.
RE: Why does the GUI block? - tangent - 02-17-2017
Quote:it's hard to make stuff concurrently in gui applications, you can't generally
allow new commands before the previous commands are done anyway
Erlang's mailboxes give you the solution: the GUI event handler just builds a message that encapsulates the desired change to the data model. (And in this case, the 3D model most of the time, too.) The mailbox lets the GUI process go back to handling user events while the OpenGL process munches on the data.
I realize that a process blocked on a many-minute bevel operation still can't update the UI to show other 3D model changes until it finishes, but you could at least respond to things like Help > About and File > Exit.
Incidentally, I just got to a different machine (not too much faster than the previous iMac) and tried the same bevel test in C4D R14, and beveling 6,144 polys is basically instantaneous. The following extrude takes only a few seconds to calculate:
![[Image: bevel-sds-sphere.png]](http://tangentsoft.com/3d/bitmaps/bevel-sds-sphere.png)
RE: Why does the GUI block? - Asticles - 02-17-2017
In blender is instantaneous, the bevel and the extrude.
In wings3d try first Inset with the faces, and then Extrude, almost instantaneous also.
Bevel lasts forever.
(edit) But after some time, it works.