IO Improvements Proposal: Documentation, Safety, Performance, Input/Output Resource
The VTK IO directory as a whole could potentially be improved in various ways:
- Documentation:
- Current Status: https://docs.vtk.org/en/latest/supported_data_formats.html lists the formats that are currently supported by VTK.
- Problem: This list is located at https://gitlab.kitware.com/vtk/vtk/-/blob/master/Documentation/docs/supported_data_formats.yaml, and since it's manually generated, it's easy to forget to update it. Many people choose libraries based on if their file formats are supported or not, and omitting to update this list could be critical.
- Suggested Solution: This list could potentially be scraped by looking
- vtk.module related information that could include file extensions supported, and format documentation
- the classes ending with Reader/Writer and get the list of classes
- and the brief description of each class
- Safety:
- Current Status: various readers when reading a file, they assume that the file is properly written.
- Problem: Files are usually properly written, but if they are not, VTK (and the applications using VTK) may crash. Also, various readers/writers use C functions, such as
atoi
, that are not memory safe which can lead to other types of crashes. - Suggested Solution: use C++ functions that perform error checking and make sure that every call of them checks for errors.
- Performance:
- Almost all readers/writer are using C functions or C++ streams
- Problem: These C functions are slow and not safe, and streams are super slow.
- Suggested Solution: Develop functions for converting string from/to values libraries such as
fast_float
,fmt
. An example isvtkValueFromString
.
- Input/Output Resource:
- Current Status: Various Readers/Writers can read from a file, and some can read also from strings
- Problem: Most readers (with the exception of the complex ones that read one Meta files to read specific files) should support reading from any type of resource such as files, or strings, or something else in the future.
vtkResourceStream
started this work to support various resources, but it's now only for reading, not writing too, and it was integrated into only 3 readers (PLY, OBJ, glTF). - Suggested Solution: Make
vtkResourceStream
bi-directionally and expand its usage to all readers/writers possible.
P.S. Feel free to edit the above description if you have further ideas or edits.
KUS: @ben.boeckel @christos.tsolakis @cory.quammen @berkgeveci @will.schroeder
KEU: @mwestphal @alexy.pellegrini
Others: @wascott @patchett2002 @acbauer
Edited by Alexy Pellegrini