Framebuffer view does not always match thumbnail for groups

[ben-clayton]

We now do 'smart' analysis to show a sensible thumbnail for a group in the command tree.
Clicking on that group will always show the framebuffer after the last command in the group.

For development Unity builds of GVR applications, the frame group ends with a non-scene framebuffer attached leading to the undefined-framebuffer pattern being shown.

We should probably just change the rules so that the command selection for a group matches the thumbnail.

[pmuetschard]

I propose we change the getFramebufferAttachment API to use the following request:

message GetFramebufferAttachmentRequest {
  path.Device device = 1;
  api.FramebufferAttachment attachment = 2;
  RenderSettings settings = 3;
  UsageHints hints = 4;

  oneof after {
    path.Command command = 5;
    path.CommandTreeNode command_tree_node = 6;
  }
}

What do you think?

[ben-clayton]

Not a bad idea. Let me investigate the amount of wiring needed to implement this.

[ben-clayton]

I got most the way through implementing this, and then suddenly wondered:

Does it make sense to have the framebuffer view show something mid-way through the group, but have everything else (state, memory, textures, etc) show the state at the end of the group?

What are your thoughts?

[dsrbecky]

Fair point, it would make sense to sync everything else to match the point at framebuffer.

In my mind, a group node should have one field which is "the representative command", and we should get the thumbnail using that. Same goes for framebuffer. And now that you mention it, it would make sense to apply it to all other state as well.

[ben-clayton]

Thanks @dsrbecky. I kinda agree, but I'm also troubled with the idea of the state not being at the end when clicking on a group or a command with children.

@AWoloszyn, @pmuetschard - what are your thoughts?

[AWoloszyn]

Sorry, I thought I had already responded.

My #1 concern would be that everything matches. It would be terrible if the State != What created the framebuffer.

That being said, I also like the idea of that being the last command in the group, but I totally understand that in some cases, the "last command" is not actually a useful piece of data to be visualizing.

Would doing something "simple" like a small area that says WHAT command this is the data for be sufficient. (Somewhere global-ish, that is always visible), then we can at least know WHICH command the thumbnail/framebuffer is for.

[pmuetschard]

I suppose we're back to my original suggestion from the proto-conversion time where tree nodes contain a Path.Command to the command that is most representative of the group. Using that path to get the FB, state, textures, etc. make sense to me. I think the same arguments that apply to choosing a representative command for the thumbnail applies here. After all, we only choose a different command than the last in the group, if we think it makes more sense.

We could show the current selection in the currently empty status bar.