RFE: state change table

[mathstuf]

It'd be nice if vogl could generate something like the table shown on slide 54 of the nVidia "Beyond Porting" talk from Steam DevDays.

[PeterLValve]

I do like this table as well, and agree that it would be a great idea to include. Unfortunately, we don't have time available internally to dedicate to this, but would be happy to offer guidance to you (or anybody else) to implement this feature. The logic to iterate over the API calls and gather the needed information would be easy to add, but designing the UI and user interaction would require some thought. If you have ideas, please share!

[mathstuf]

Would you mind putting the instructions here for anyone who might want to implement it? (Or a wiki page if that's more applicable.)

[plohrmann]

I leave data structures and UI design up to you, but in regards to iterating over the API calls, take a look at vogleditor_QApiCallTreeModel::find_net_drawcall(..). This function starts at the currently selected node (found via iter.findNext(start)) and iterates over the nodes in the call tree. If the node is an apiCallItem it will check the gl_entrypoint_id_t against known draw call entrypoint IDs and return indicating that it found the next draw call.

In order to generate a state table as shown above, you can user the iter just as it is created, without moving the 'start' node, and as the loop iterates to find a draw call, check all the nodes along the way for entrypoints that would change the desired state. A naive approach might just look for the entrypoints that could modify the state (ie: glBindFramebuffer, glUseProgram, etc) to flag whether the state has changed, while a more intelligent approach would track the currently bound object and check the entrypoint parameters to see if the object had changed. A bonus feature would be to keep track of the API call index of the changed state and/or the object that it was changed from/to so that the user might be able to click on the state change table and jump to the api call and object that was modified.

Another approach that just popped into my head (and would be useful for several other features) would be to take a state snapshot at each draw call and use the state tree diff'ing feature to detect whether a specific piece of state had changed from the previous snapshot. Benefit of this is that you should be able to easily get the object that was previously bound, and you'll already have a snapshot so that you can click & jump to the object that was changed. However, there is likely still a limitation as to how many snapshots we can have in memory at one time, and that might make this approach a can of worms to implement. Also, taking a snapshot at every draw call is likely to be quite slow on large applications, so the previous approach might be the best starting point.

[mathstuf]

Looking at the code, would it make sense to add flags for gl_entrypoint_desc_t::m_flags for what states a call can change? This would make it possible to have a column in the API call tree with an array of state changes (since we just check what state a call changed).

For UI, I was thinking that a table would be generated for a single frame with a number in the box for how many times it was changed between each draw call. When clicked, they would act as the tabs for a listview of the call sites which changed the state and clicking on it would be linked with the current tree view. In fact, it might be implementable as a separate view altogether which just shares a model with the API tree.

[mathstuf]

Since I won't get it done right now, here's a braindump of my thoughts so far:

• write a delegate which does the tabview/list magic
  • need to look into how to write a delegate which combines items into a single row in the view
• link the state table with the API which clicking/searching around
• look into Navigating apicall tree with State/Render operations #161 to see how its changes to vogleditor_QApiCallTreeModel muddy the waters for sharing the model (the new view might be able to just ignore any groupings)

[lawlove]

look into #161 to see how its changes to vogleditor_QApiCallTreeModel
muddy the waters for sharing the model (the new view might be able to just
ignore any groupings)

​Yes I think that should be true (ignore any groupings);
vogleditor_QApiCallTreeModel contains the ​list (m_itemList) of all its
(tree model's) vogleditor_apiCallTreeItem objects from which can be queried
as to whether it is a root, frame, group, or apicall type tree item.

Peter Lohrmann suggested using the State/Render groups as hooks into color
coding the timeline which, as you noted in a #161 comment, looks related to
having a state change table. Another option might be to have the timeline
color coding dynamically configurable (via a UI) for different criteria.

​​I plan on keeping the group stuff modular so as to be easily
enabled/disabled which can then be set by a UI (as suggested by Lohrmann)
or even pulled out if ultimately decided not to be useful, too muddy, to
use a different design, etc.

On Fri, Sep 5, 2014 at 9:11 AM, Ben Boeckel [email protected]
wrote:

Since I won't get it done right now, here's a braindump of my thoughts so
far:

• write a delegate which does the tabview/list magic
• need to look into how to write a delegate which combines items
  into a single row in the view
  - link the state table with the API which clicking/searching around
• look into Navigating apicall tree with State/Render operations #161 Navigating apicall tree with State/Render operations #161
  to see how its changes to vogleditor_QApiCallTreeModel muddy the
  waters for sharing the model (the new view might be able to just ignore any
  groupings)

—
Reply to this email directly or view it on GitHub
#102 (comment).