[Bug] 3d visualizer becomes extremely slow without axis disabled #1663
Comments
…n (issue WerWolv#1663). It is not clear what is causing this bug. There is an optimization at the 2-d level that skips frames that are repeating the exact same draw calls that could be related but no reasonably detailed explanation as to how that is causing lag has been put forth. The bug exhibits itself as a frame-locking of all windows according to their draw-lists updating frequency. If there are changes that occur 30 times a second anf this is the fastest occurring change then no windows will be allowed to update at a faster rate. The other major key is that only changes that are created using draw-list will be taken into account to set the locking rate. This explains why the bug is not present when the axes are shown since part of the axes are also the text labels "x","y" amd "z". Since the labels are constantly moving when rotating or translating the model then the draw-lists for these labels become the fastest changing ones. Note that the changes don't need to be visible, they just need to have a draw-list that updates at the desired rate. To be clear about what this is, this is a fix for the lag seen under certain circumstances when using the 3d-visualizer. What this is not, is a fix for any or all underlying issues that may or may not exist in the code that affects rate locking or rate synchronization in ImHex. In that context it is not a workaround as it addresses the main issue (the lag) by making sure that there is a 2d draw-list associated with the display which is what is causing this bug (this i to say this fixes a bug of the 3d visualizer fixed using code from 3d_model.cpp , not a bug in windows.cpp which has code I am not familiar with). Adding a few vertices and indices to lists of potentially thousands of them is not going to have a measurable impact and honestly, the 3d -visualization tool is not sophisticated enough for us to worry about its performance after adding a letter or two. The fix is very simple. We are already drawing 2d components in the 3d view when the axes are turned on, so adding three numbers for the x y and scroll numbers in the same color as the background is not a hack, it is the only way to fix the problem from within the visualizer code. That also means that it is not a workaround for the bug in question. If there is a bug deep in the rendering code of ImHex then that bug needs to be found first before it can be fixed. Turning off the entire 2d optimization to avoid the lag would be considered a workaround for that bug. What needs to be done to fix the bug is to find a way to incorporate the 3d window into the 2d optimization. At any rate, that's a separate bug that may or may not be related to the one being fixed here. Additionally, the changes proposed here will not affect changes to fix the other bug if such a bug does in fact exist because the 3d visualizer code is at another separate level. Without the intervention of those who know the rendering code well enough to make changes without creating bigger problems than the ones being solved, this is the best solution I can offer (and yes, it completely removes the lag)
|
To be able to reproduce this issue several conditions must be met that are not described in the description above. The conditions also affect how the issue manifests itself. The conditions are:
Under those conditions you will experience lag on the rotations and translations and scaling of the model. Just how much lag depends on whether you have the option Extra>Settings>Interface tab=>"Show resources in footer" on or off. If it is on then the model will update when the % cpu updates to show a new value. If it is off the model updates when you hover over the icons or the reset button. If you are rotating the model with the middle click, the model will not update by simply lifting the middle button, you have to hover the items described for that to happen. |
|
The reason for the bug, as will be shown soon, is that the lag occurs when there are no draw calls changing between frames despite the fact that the 3d contents is changing. The reason the 3-d changes become invisible to the optimization code should be obvious. There are no draw calls being made from the opengl code that renders the visualization. It is true that a texture is created, but it isn't being displayed using draw calls. To see this we turn to the Imgui demo and the I found the code in the demo that renders the draw call highlights and made changes to it so that the draw calls of the 3-dvisulaizer window are always drawn. When the name of the window contains Popup it calls Recording.42.mp4As you can see, the 3d display does not produce draw calls, so the optimization thinks there are no changes in the display and skips the rendering until some other part of the window updates as explained in my previous post, thus creating the lag. There are two possible approaches that I can think will solve the problem. The easiest to imagine and implement is to add a permanent draw call to 3d windows that updates every frame. The other would be to communicate to the function doing the optimization that there's a 3-d image and have the optimization turned off. I know how to implement the first but not the second and looking into it doesn't seem worth it when an equally good solution that's easier to implement is available. UPDATE: After doing some research I found a way to identify the 3d window when it becomes one of the commands that belongs to the main window which happens when the 3-d window is completely overlapping the main window. All commands have an _OwnerName which is a string with the name of the window. All 3-d windows have |
The bug was caused by an optimization of the display rendering that uses drawlists to detect changes. The changes in the 3-d visualizer don't contain drawlists when axes are turned off. The fix is to identify the 3d visualizer among the command lists of the main window and, if found, avoid skipping frames regardless of the result of the comparison of drawlists.
Operating System
Windows
What's the issue you encountered?
Whenever the axis are disabled for the 3d visualizer, every rotation takes a few seconds to apply and only applies after having let go of the middle mouse button.
How can the issue be reproduced?
open a 3d model file and run its pattern
open the 3d visualiser
disable the axis (every other option doesn't matter)
try to rotate the model. Wait a bit between interactions
enable axis again
successfully rotate the object accurately again
ImHex Version
1.33.2 (latest nightly
ImHex Build Type
Installation type
MSI
Additional context?
unable the model due to copyright concerns. Please contact me on discord if needed (same username)
The text was updated successfully, but these errors were encountered: