Changes

Jump to navigation Jump to search
m
Line 7: Line 7:  
And in fact, it would also be possible to overload setprop/props.Node per MFD instance to transparently use your helpers, while that would not provide ideal performance, it could get some people going more quickly.
 
And in fact, it would also be possible to overload setprop/props.Node per MFD instance to transparently use your helpers, while that would not provide ideal performance, it could get some people going more quickly.
   −
Back when we were profiling the FG1000, the one thing that would be required to use Nasal thread.newthread() API for SVG handling was delaying execution of code that expects certain SVG IDs to be around already - right now, the most common idom is a for-loop to traverse a data structure and get a handle to a bunch of SVG elements per SVG file, so that these can be individually update/animated. So we usually traverse a bunch of files to get a bunch of element IDs and then run all the initialization afterwards - if the "SVG initialization" workflow were to become a dedicated idiom as part of the MFD framework, Nasal could spawn a few worker threads, do all the parsing by getting file names/callbacks from vector and then use a partition processor to do all the property I/O spread across multiple frames that would then run in the main loop afterwards. Again, with the current FG1000 init I am seeing roughly ~15 seconds of delay due to SVG handling on less powerful systems, once SVG files are processed in parallel, that delay goes down to roughly 5 seconds - I haven't yet tried spreading out the callback handling to set up Canvas elements in separate frames, but I believe with your work, this could be a very promising way forward without introducing breakage - and using a thread pool/job queue threads could still be optional, too.
+
Back when we were profiling the FG1000, the one thing that would be required to use Nasal thread.newthread() API for SVG handling was delaying execution of code that expects certain SVG IDs to be around already - right now, the most common idom is a for-loop to traverse a data structure and get a handle to a bunch of SVG elements per SVG file, so that these can be individually update/animated. So we usually traverse a bunch of files to get a bunch of element IDs and then run all the initialization afterwards - if the "SVG initialization" workflow were to become a dedicated idiom as part of the MFD framework, Nasal could spawn a few worker threads, do all the parsing by getting file names/callbacks from vector and then use a partition processor to do all the property I/O spread across multiple frames that would then run in the main loop afterwards. Again, with the current FG1000 init I am seeing roughly ~15 seconds of delay due to SVG handling on less powerful systems, once SVG files are processed in parallel, that delay goes down to roughly 5 seconds - I haven't yet tried spreading out the callback handling to set up Canvas elements in separate frames, but I believe with your work, this could be a very promising way forward without introducing breakage (possibly using Emesary to register SVG files to be processed by worker threads) - and using a thread pool/job queue threads could still be optional, too.
 
I think Stuart, James and jsb actually commented on the fact that they'd like to keep SVG handling in Nasal space due to the flexibility it provides, compared to native handling via librsvg (which would require some C++ work): [[Canvas SVG]] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:23, 5 December 2020 (EST)
 
I think Stuart, James and jsb actually commented on the fact that they'd like to keep SVG handling in Nasal space due to the flexibility it provides, compared to native handling via librsvg (which would require some C++ work): [[Canvas SVG]] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:23, 5 December 2020 (EST)
  

Navigation menu