thinking about the data source, background loading and data transport mess #975
Conversation
This is just about the structure and the interfaces. Do we want to put more restrictions? Or Less?
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
| // here we should actually grab the frames from some background thread that reads ahead and stuff? | ||
| FrameType f; | ||
| f.Read(IndexToIStream(idx)); | ||
| return std::make_unique<FrameType>(f); |
There was a problem hiding this comment.
Use std::move(f) and demand that FrameType is moveable (C++ concepts?)
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
| } | ||
|
|
||
| // data will be controlled by this instance, caller loses access! | ||
| void SetData(uint8_t* data, std::size_t count, ImageElementType channelType, SizeType width = 1, SizeType height = 1, SizeType depth = 1) { |
| } | ||
|
|
||
| template <typename ResultType> | ||
| std::vector<ResultType> GetCopy() { |
There was a problem hiding this comment.
The switch-case part in the following functions can be in a separate method using a functor for copy/set/get functionality
| default: | ||
| throw std::logic_error("ImageFrame::GetCopy: invalid elementType"); | ||
| } | ||
| return std::move(out); |
|
|
||
| template<typename Dest, typename Source> | ||
| void CopyInto(std::vector<Dest>& out) { | ||
| std::transform(ViewAs<Source>(), ViewAs<Source>() + NumElements(), std::back_inserter(out), |
There was a problem hiding this comment.
Method hides whether reserve or resize should be used for out
| // typename ChannelType does not work, that is not a static decision. | ||
| // For some data sources you only know after actually opening the file what's in it. | ||
| // TODO: volume ist ein byte-vektor und wir benutzen span. fertig. | ||
| template<uint8_t Dimensions> |
There was a problem hiding this comment.
Do we need dimension as static information since we do not change available methods?
There was a problem hiding this comment.
I was wondering whether we should disable some of the methods depending on Dimensions. I am really not sure whether we should just treat dims dynamically too. A transfer function is a perfectly OK volume, strictly speaking. It's a bit thin, but not broken or something...
There was a problem hiding this comment.
With the dimension discerning types, we have either three statically different call transporting 1D, 2D, or 3D volumes, or yet another dispatch. I would argue for dimension as template parameter, if we have a significant gain from it.
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
…g a separate input renderer, and to render into the provided framebuffer
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
open questions: