Also see the discussion at #201 (comment)
In the case that we have very large datasets, two instrumentation report graphs (the gantt timeline and the parallelism chart, which use the same underlying implementation) will be created using matplotlib and rasterized to a PNG. This is for both space reasons (to stop generating HTML for graphs that grows to potentially dozens or hundreds of MiB), and for performance reasons (turns out that graphs that get that large do not perform very well in the browser anyway).
The current InstrumentationVisualizer interface assumes that you're just returning a string HTML fragment and not generating any other files. This needs to be reworked so that we can save the PNG directly and refer to it with a simple relative link in the HTML report, to help save on file size and follow best practices. The existing ReportArtifacts type somewhat already covers this use case, but is used primarily for the simulation report flows which already use multiple HTML files.
This could also be taken a step further - each HTML report fragment could be its own seperate page which is loaded & served via HTMX. Some re-architecting of the instrumentation report flow will likely be required to facilitate this however.
Also see the discussion at #201 (comment)
In the case that we have very large datasets, two instrumentation report graphs (the gantt timeline and the parallelism chart, which use the same underlying implementation) will be created using matplotlib and rasterized to a PNG. This is for both space reasons (to stop generating HTML for graphs that grows to potentially dozens or hundreds of MiB), and for performance reasons (turns out that graphs that get that large do not perform very well in the browser anyway).
The current
InstrumentationVisualizerinterface assumes that you're just returning a string HTML fragment and not generating any other files. This needs to be reworked so that we can save the PNG directly and refer to it with a simple relative link in the HTML report, to help save on file size and follow best practices. The existingReportArtifactstype somewhat already covers this use case, but is used primarily for the simulation report flows which already use multiple HTML files.This could also be taken a step further - each HTML report fragment could be its own seperate page which is loaded & served via HTMX. Some re-architecting of the instrumentation report flow will likely be required to facilitate this however.