If I target a default button with an opview, the opview reports a cooktime of 0.3-0.5 ms.
And if I target a more complex panel the cooktime quickly goes up to multiple ms
Why is that? I though a panel is already present as a “texture”, so I expected that the conversion to a TOP is super efficient
To clarify, you are referring to OP Viewer TOP? There is also the COMP…
Hi Ben,
yes, i was talking about the opviewer TOP . Just hover with your mouse over the panel (to force a cook) and watch the cooktime. Its ~1ms on my system . If I delete all except one button (inside the container) it is still 0.4 ms
opview.toe (6.4 KB)
Ok, thanks for the example. On my system it is only ~0.4-0.5ms, and down to under 0.1ms for just 1 button (2022.28040).
I’ll ask a dev for input here, what is your system spec?
~3 year old precision 772? laptop in its top config , quadro 5200, fastest Xeon available at that time
On my desktop I get similar numbers as you, but still think that those 0.4~0.5 seems rather high
I’ve added this to my TODO to take a closer look at. Thanks for the report.
To answer this part though: no, the panel isn’t a texture. The OP Viewer TOP creates a texture by re-rendering the UI at the desired resolution with the current UI state. So it’s a full render that’s occurring, not a texture copy.
I think in general this will be sped up in 40K where we plan to improve the UI rendering speeds.
ok, but where is the mismatch in cooktimes coming from? In this updated example cook.tox (4.5 KB)
one node inside the container cooks, and the container reports a static initial cooktime and a small (0.03) changing cooktime for the single cooking button inside. That’s it.
But the opview TOP reports a 1 ms CPU cooktime every frame. So if a full render of those buttons takes 1 ms , why isn’t the container reporting the same 1ms cooktime.
And in regards to GPU cooktime. The container always reports 0 ms, is that correct?
Assumptions: The Comps (just like the new TextCOMP) do directly draw to the screen. This means there is no need to do alot of operatins that are done otherwise in TOP world, mainly allocating memory, pushin stuff there.
Imagine it like GEOs and a renderTOP. The Geometry does not cook but still gets displayed in the renderstep, and even if you do changes (transformations), they are relatively quick compared to a transformation in TOP-world.
Yes exactly. Unlike a TOP, which does a render to generate a texture during it’s cook, a Panel COMP is mostly just evaluating it’s parameters to setup a description of how the UI should look. The actual rendering happens any time that UI needs to be shown, possibly multiple times in a frame, outside of the cook. Such as when the UI is shown in a node viewer, in the Op Viewer TOP, in a panel viewer, as a sub-panel in a larger panel.
This can be most notably seen with the Text COMP, where it you can show it in multiple places/resolutions at the same time, and it always looks good. If it was a texture rendered offscreen then it would look pixelated in some places vs. others (as the Text TOP does when used for text in a panel).
Yes, the GPU cook time is correct since no GPU operations are done during it’s cook.
Thank you for the detail explanation Malcolm