Another chaotic swirl.

The next problem with the software port was with AppDomains. An AppDomain is an isolated environment to run a program, or a part of a program. Every program runs in an AppDomain. The main program AppDomain is created when the program starts and taken down when the program exits. You never notice it or think about it. The tricky part is when you want more than one AppDomain.

A second AppDomain is useful with add-on code as described in the last couple of posts. If you load a program add-on into the main AppDomain, you cannot get rid of the add-on without terminating the main program. By loading the add-on into a separate AppDomain, you can discard the AppDomain, and the add-on code when you are done with it. I do this to recover the memory space used by the add-on, and to protect against crashes. The add-on code tends to be more experimental and less tested than the main program code.

My art program is the only program I have that uses more than one AppDomain. So I am deep into the port to VS 2022 when I learn that AppDomain support has been removed from .Net 6. Not changed, just flat out not supported.

The next best thing appears to be the AssemblyLoadContext class. You can load the add-on dll into a separate AssemblyLoadContext. When the add-on is done running the garbage collector eventually runs and frees the space. Well that is the theory at least.

There is a known bug with AssemblyLoadContext garbage collection when it runs WPF (Windows Presentation Foundation) code. WPF creates objects for windows and other display components. Some of these objects are never released, even after the window is closed. That prevents garbage collection. At the time I was discovering these problems the recommended work-around was the ever-so-helpful "just don't do that". In my case, my add-ons often come with custom editors which use WPF, so the recommended "solution" is not feasible. It may have been fixed by now, but I am not in a mood to fight that battle again.

I have given up on AppDomain and AssemblyLoadContext. Computers have so much memory these days, that worrying about add-on code memory use is a misplaced concerned. The memory used by the add-on program code is insignificant compared to the memory used for a single high resolution picture. As for program code defects, I just need to be more careful.

My posts have slowed down in the last three months. My program port to VS2022 has been complete for some time now. Previously I described two problems with the port. The first was solved by loading unnecessary dlls to get the compiler to work. The second, AssemblyLoadContext is a poor substitute for AppDomain, has two consequences; it wastes memory and prevents recovery when an add-on crashes or hangs. I grew up in an era where external storage access and memory were expensive. I need to keep reminding myself that this is not a problem in the 21st century. And if an add-on fails, I terminate the run and restart in debug mode. It does not happen often and when it does I usually need the debug tools to find fix the flaws anyway.

The new Visual Studio is working now. I decided that while I had the hood open, it would be a good time to tweak some other things. I had a long list of things that work, but could be made to work better.

Of course little things tend to become big things, and that great alternate design turns out to not be so great. I just accept that this is part of the process of learning and improving. I am not going to bore you with the details. It is mentioned only to provide an excuse for the recent scarcity of blog posts.

Along the way while making these program changes, I create test images. The main motivation is of course to test and explore new ideas. Some of those test images are interesting on their own. I classify these as "work in process" and save them to develop further in the future. For now, I need to keep focus on adding / improving program features.

This one gives an impression of colored lights in a dark room.

Another one with imaginary lights reflecting off an invisible surface.

Inspired by topographical maps.

While working on an algorithm to detect the intersection of two objects, some tests were needed. I put together test cases for various simple 2d and 3d objects such as lines, planes, spheres. For a more challenging test case, I created an bumpy terrain and tried to intersect it with a flat rectangle.

The test passed immediately, but I headed off on a tangent to create interesting, surreal landscapes. The results of that foray make up the next few posts.