Navigating apicall tree with State/Render operations

[lawlove]

A suggestion was made that modifying the UI such that state and render operations were grouped into separate tree nodes would be helpful. A proof-of-concept version is at https://github.com/lawlove/vogl/tree/state-render-groups-demo. Any feedback is welcome.
So something like this:

In addition to the State change and Render containers, other push/pop (glPush/PopDebugGroup) apicalls and nested glBegin/End apicalls are still recognized:

Clicking on the higher level node will move the marker along the timeline in addition to drilling down to the individual calls.

Details

The rule for processing the calls is that every glPush apicall starts a push down into a new level in the tree; every glPop apicall pops up one level.

Other gl calls are collected into a block, or "chunk", of calls. If a RENDER (framebuffer write) operation occurs (e.g. draw, clear, glEnd, glBitmap), then it closes the current chunk and names it. Since this chunk is now closed, any subsequent call starts a new chunk. When a glPush/Pop apicall is encountered and there is an open chunk, then that chunk will be implicitly closed with the name "State changes". glBegin/End apicalls are nested within RENDER chunks.

The fully expanded tree would expand to every gl call but omitting the PushDebugGroup and PopDebugGroup; they must necessarily exist for as group markers but have no purpose other than to name those groups.

Note: this branch is just a demo. It's not production. If an acceptable feature I'll continue working on it.

[plohrmann]

Can you reference where the original suggestion came from?

Ideas / comments from highest priority to 'would be nice':

1. Add a way to toggle between modes so that users can easily just see the draw calls without other clutter and clicking - perhaps a combo box so that we can easily add more hierarchy methods without consuming too much toolbar space?

2. Another request would be to support glPushDebugGroup/glPopDebugGroup separately from the state changes. I'd expect developers to know what their debug group names mean, but just seeing "State Changes" may not tell them anything useful.

3. I'd really like to see this tied in with Issue Alternative views and color codings for timeline (call types, reads, debug groups, etc) #121, such that going into the state/render view would change the color coding of the timeline items. There should be a commented out line that will get the color from the state timeline object itself instead of calculating it based on timeline item duration. The idea would be that when constructing the timeline we can assign colors to the items which will be used to draw them. At the time of writing I didn't have any useful colors to assign, so decided to use duration to calculate one. In alignment with second request - each Debug Group would get assigned a different color in the timeline. My thought was to use the address of the supplied string (possibly with some bit-shifting) in such a way that we'll get visibly unique colors for each group. To tie this in with the next request, the timeline items could be colored based on which part of the pipeline the state changes are affecting.

4. Someone recently requested being able to identify which pieces of state changed - it would be great if instead of just naming the node "State changes" you could also indicate which parts of the pipeline: "State changes (VAO, FS, FBO)"

[lawlove]

Hi Peter,

Thanks for the great input.

This was communicated to me from Intel's OTC Visualization and Media group
but wide open for refinement of course. Everything you suggest sounds great
and makes good sense​. Depending on time, I'll try to accommodate at least
the first two. I probably won't get the time but will keep an eye on the
color coding (I overlooked issue #121. Also noted commented out line in
vogleditor_QTimelineView::drawTimelineItem) and keeping the code
facilitative for item 4.

I'll make updates on progress.

Thanks again,
Larry

On Mon, Aug 25, 2014 at 2:25 PM, Peter Lohrmann [email protected]
wrote:

Can you reference where the original suggestion came from?

Ideas / comments from highest priority to 'would be nice':

1. Add a way to toggle between modes so that users can easily just see the
   draw calls without other clutter and clicking - perhaps a combo box so that
   we can easily add more hierarchy methods without consuming too much toolbar
   space?

2. Another request would be to support glPushDebugGroup/glPopDebugGroup
   separately from the state changes. I'd expect developers to know what their
   debug group names mean, but just seeing "State Changes" may not tell them
   anything useful.

3. I'd really like to see this tied in with Issue Alternative views and color codings for timeline (call types, reads, debug groups, etc) #121
   Alternative views and color codings for timeline (call types, reads, debug groups, etc) #121, such that going into
   the state/render view would change the color coding of the timeline items.
   There should be a commented out line that will get the color from the state
   timeline object itself instead of calculating it based on timeline item
   duration. The idea would be that when constructing the timeline we can
   assign colors to the items which will be used to draw them. At the time of
   writing I didn't have any useful colors to assign, so decided to use
   duration to calculate one. In alignment with second request - each Debug
   Group would get assigned a different color in the timeline. My thought was
   to use the address of the supplied string (possibly with some bit-shifting)
   in such a way that we'll get visibly unique colors for each group. To tie
   this in with the next request, the timeline items could be colored based on
   which part of the pipeline the state changes are affecting.

4. Someone recently requested being able to identify which pieces of state
   changed - it would be great if instead of just naming the node "State
   changes" you could also indicate which parts of the pipeline: "State
   changes (VAO, FS, FBO)"

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

[mathstuf]

Looks related to #102 as well.

[lawlove]

1. Add a way to toggle between modes so that users can easily just see the draw calls without other clutter and clicking - perhaps a combo box so that we can easily add more hierarchy methods without consuming too much toolbar space?

I've put this control in the settings dialog if that's acceptable.

I don't have it completely hooked up yet but currently when something is changed on this tab and saved, the tree will dynamically change to display the new characteristics.

[plohrmann]

Looks great to me so far! Thanks Larry!

On Fri, Oct 24, 2014 at 5:18 PM, Lawrence Love [email protected]
wrote:

1. Add a way to toggle between modes so that users can easily just see the
   draw calls without other clutter and clicking - perhaps a combo box so that
   we can easily add more hierarchy methods without consuming too much toolbar
   space?

I've put this control in the settings dialog if that's acceptable.
[image: vogl-group-settings02]
https://cloud.githubusercontent.com/assets/6090880/4778023/4696d896-5bdb-11e4-97b8-b7a8914a8d82.png

I don't have it completely hooked up yet but currently when something is
changed on this tab and saved, the tree will dynamically change to display
the new characteristics.

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