Current output logging type mechanism's performance goes down once the number of lines keeps increasing. Performance is inversely proportional to the output rendered per module. The current method, prepending/appending text nodes consistently to the output window, is causing the memory to eventually degrade the rendering performance. This also affects other single-line refresh output type's performance too. This sums up that current rendering methods are prone to performance degrade based on number of modules that uses any type of rendering mechanism.
This suggests the need for new Output Rendering mechanism.
Recommendations for new output window:
First priority -- WebGL-based, scrollable
Second priority -- WebGL-based, non-scrollable
Third priority -- HTML Canvas-based, scrollable
Fallback -- HTML Canvas-based, non-scrollable
NOTE: The effort taken should worth it. It is strictly advised to conduct a thorough research first on the alternative possibilities given above and see whether their downsides will account to the profitability for the effort taken on doing the actual changes in implementation. The technology/method used should not be an overkill for the use case considering the challenges it has to resolve, meaning, a full-fledged and feature-packed graphics/game framework/library used to build complex games might not be needed in this case.
Current output logging type mechanism's performance goes down once the number of lines keeps increasing. Performance is inversely proportional to the output rendered per module. The current method, prepending/appending text nodes consistently to the output window, is causing the memory to eventually degrade the rendering performance. This also affects other single-line refresh output type's performance too. This sums up that current rendering methods are prone to performance degrade based on number of modules that uses any type of rendering mechanism. This suggests the need for new Output Rendering mechanism.
Recommendations for new output window: First priority -- WebGL-based, scrollable Second priority -- WebGL-based, non-scrollable Third priority -- HTML Canvas-based, scrollable Fallback -- HTML Canvas-based, non-scrollable
NOTE: The effort taken should worth it. It is strictly advised to conduct a thorough research first on the alternative possibilities given above and see whether their downsides will account to the profitability for the effort taken on doing the actual changes in implementation. The technology/method used should not be an overkill for the use case considering the challenges it has to resolve, meaning, a full-fledged and feature-packed graphics/game framework/library used to build complex games might not be needed in this case.