With the exception of some minor visual issues, a few on iOS and quite a few on Android things seem to be starting to stabilize. Once I fix these visual problems, thing will be in extremely good shape on iOS. Android however, I am noticing a bit of an issue that might be harder to address. Performance.
Interface Builder is an extreme test of the Dynamic Windows API. Recreating interface elements on the fly. Destroying parts of the interface and recreating them. I have two tablets, of similar age, (2018 iPad and 2019 Fire HD) but comparative performance, the Android tablet recreating the interface is very slow. Like when I touch an interface node in the tree, I watch the properties inspector recreate the interface line by line. Whereas on the iPad it is essentially instantaneous like on the desktop platforms.
Both platforms have the user code running in one thread and the UI thread running separately, with a need for the user thread to call into the UI thread to make changes to the user interface, however on Android it isn't just calling into a different thread, it also calls into a totally different language. The UI code is in Kotlin/Java and has to cross over a JNI which the documentation warns is expensive to do. However keeping with the Dynamic Windows design goal of writing DW code once and running it on all supported platforms, I don't really see another way than JNI.
Once I work out these visual problems I think I will need to spend some time to figure out how to speed up these code transitions, I am not sure the performance is acceptable currently, at least on my current testing hardware.
Update: I've been looking at the code in a bit more depth, and I think I see what may be a contributing factor to the slowness. dw_window_get_data() calls.... Interface Builder makes tons of calls to this, and they all result in a JNI call to look up the data. If dw_window_s/get_data() could be redesigned so they don't require JNI calls the performance could be drastically improved. It is a simple data lookup which doesn't need to be run in a UI context or even in Kotlin/Java... that is just how I originally designed it.
Update 2: That did not seem to fix the performance issues, so will need more research... I updated the plan for the new version in the Dynamic Windows sub-forum: https://dbsoft.org/forum/showthread.php?...553#pid553
Interface Builder is an extreme test of the Dynamic Windows API. Recreating interface elements on the fly. Destroying parts of the interface and recreating them. I have two tablets, of similar age, (2018 iPad and 2019 Fire HD) but comparative performance, the Android tablet recreating the interface is very slow. Like when I touch an interface node in the tree, I watch the properties inspector recreate the interface line by line. Whereas on the iPad it is essentially instantaneous like on the desktop platforms.
Both platforms have the user code running in one thread and the UI thread running separately, with a need for the user thread to call into the UI thread to make changes to the user interface, however on Android it isn't just calling into a different thread, it also calls into a totally different language. The UI code is in Kotlin/Java and has to cross over a JNI which the documentation warns is expensive to do. However keeping with the Dynamic Windows design goal of writing DW code once and running it on all supported platforms, I don't really see another way than JNI.
Once I work out these visual problems I think I will need to spend some time to figure out how to speed up these code transitions, I am not sure the performance is acceptable currently, at least on my current testing hardware.
Update: I've been looking at the code in a bit more depth, and I think I see what may be a contributing factor to the slowness. dw_window_get_data() calls.... Interface Builder makes tons of calls to this, and they all result in a JNI call to look up the data. If dw_window_s/get_data() could be redesigned so they don't require JNI calls the performance could be drastically improved. It is a simple data lookup which doesn't need to be run in a UI context or even in Kotlin/Java... that is just how I originally designed it.
Update 2: That did not seem to fix the performance issues, so will need more research... I updated the plan for the new version in the Dynamic Windows sub-forum: https://dbsoft.org/forum/showthread.php?...553#pid553