Re:About the IMGUI Paradigm
by dsp_person on Saturday August 24, 2024 @12:40AM
(#41335698)
That sounds exactly like a scroll area. For example Dear ImGui has scrolling based on a draw list which will be clipped to the current visible area. Nothing stopping adding panning and zoom controls for this. In fact I saw mouse panning added in one of the ImColorTextEdit forks. Maybe Dear Imgui doesn't have a "zoom" feature built-in, but I don't imagine that being hard to implement. Just additional scaling and clipping to the draw list.
[ Parent
| on HN ]
Re:About the IMGUI Paradigm
by 0x1ceb00da on Saturday August 24, 2024 @08:48AM
(#41337888)
Can it be done outside of the library in the user code?
Re:About the IMGUI Paradigm
by dsp_person on Saturday August 24, 2024 @03:14PM
(#41340663)
Click to drag yes since it's just using ImGui::SetScrollX, ImGui::SetScrollY based on mouse events. For zoom, it could be in user code if it's your own custom widgets or rendering with ImGui::GetWindowDrawList()->Add{Something}, but I don't think Dear ImGui has a super great api for zoom with the built in windows/widgets like we're talking about here. It's a limitation of this api, not the immediate mode paradigm in general (like the article argues).
For example, ImColorTextEdit renders an ImGui:Dummy() to create a dummy widget of a specified width and height which defines the scroll area, and then based on the current ImGui::GetScrollX() and ImGui::GetScrollY() it uses ImGui::GetWindowDrawList()->Add{Rectangle,Line,Text, etc} to custom render the contents inside the widget based on what should be visible at the scroll positions. Since it's custom code it would be easy to use a zoom param to adjust the scale of things and what is submitted to the draw list.