RenderingEndPoint #1147
RenderingEndPoint #1147
Conversation
Infrastructure for passing resources to windows
|
Style check found formatting issues! Comment |
| ep_v.entry_point_data->update(); | ||
|
|
||
| ep_v.execute(ep_v.modulePtr, ep_v.entry_point_resources, ep_v.execution_result_image); |
There was a problem hiding this comment.
This is already done by the image presentation service once a framce for each registered entry point. Triggering re-rendering of a frame from inside the GUI seems a bad idea. The intended approach is to then use the ep_v.execution_result_image texture handle (either GL or CPU texture) to present the rendered texture in an ImGui window.
There was a problem hiding this comment.
The rendering execution result image is only available after entry point/graph execution, which introduces a recursive dependency on showing the entry point results in the GUI, which itself is rendered as an entry point.
| ep_v.entry_point_data->update(); | ||
|
|
||
| ep_v.execute(ep_v.modulePtr, ep_v.entry_point_resources, ep_v.execution_result_image); |
There was a problem hiding this comment.
I suppose dragging the frontend resources up until here would also be not necessary without executing the entry points?
|
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 |
|
/format |
| #include "AbstractWindow.h" | ||
|
|
||
| #include "ImagePresentationEntryPoints.h" | ||
| #include "ImagePresentation_Service.hpp" |
There was a problem hiding this comment.
This dependency between GUI (GUI Service) and Image Presentation Service may lead to problems. For cleaner separation of code it will be cleaner to pull the dependencies from ImagePresentation_Service.hpp into a separate header or otherwise restructure the affected code.
| wrapped_images.push_back(entry.execution_result_image); | ||
| auto const& sink_list = ep_sink_map[entry.moduleName]; | ||
| for (auto const& sink : sink_list) { | ||
| sink_img_map[sink].push_back(entry.execution_result_image); |
There was a problem hiding this comment.
I am not sure about the details but it might lead to many GL texture / Byte texture copy operations when putting ImageWrapper execution_result_image in different places. I believe the initial goal for the ImageWrapper was to have a lightweight abstraction over GL/Byte textures with the option to transform one into the other (texture down/upload). It may be that the ImageWrapper copy constructor also copies textures/vectors internally, depending on whether the held texture is only referenced or actually owned.
|
Style check found formatting issues! Comment |
|
/format |
|
Style check found formatting issues! Comment |
|
Style check found formatting issues! Comment |
|
/format |
|
Style check found formatting issues! Comment |
Replace SplitView with RenderingEndPoints in ImGui (requires docking feature).
Summary of Changes