gfxreconstruct
gfxreconstruct copied to clipboard
LunarG
docs: Add an overview of block definitions
Adds a markdown file containing a high level overview of blocks along with generated block definitions for reference.
I think it's a little hard to read in it's current state:
Maybe hand-modify the tables to get rid of tables in tables.
Instead, merge the sub-tables into columns with the main table:
| Name | Block Type | Payload/Variants | |||
| Name | Type | Count | Details | ||
| FunctionCall | kFunctionCallBlock | api_call_id | APICallId | 1 | |
| thread_id | u64 | 1 | Uniquely identifies the thread that made the API call. | ||
| parameter_buffer | compressible_bytes | 1 | A sequence of bytes containing the serialized parameters for the API call. | ||
OR, you could also just pull out the payload/variant tables into separate areas and just reference them from each block.
My concern is right now it's very hard to read.
I agree it's not very readable and I don't have a good grasp on a solution to make it more "digestable," so I'll give this a try.
For the "separating payloads out" approach, are you thinking a table with block names that references another table of payloads?
Another possibility is to have each block be a subsection (see example below), but again I'm not sure if that's any clearer.
Blocks
FunctionCall (kFunctionCallBlock)
Record of a function called in the application.
| Payload | |||
|---|---|---|---|
| Field name | Type | Count | Details |
| api_call_id | APICallId | 1 | |
| thread_id | u64 | 1 | Uniquely identifies the thread that made the API call. |
| parameter_buffer | compressible_bytes | 1 | A sequence of bytes containing the serialized parameters for the API call. |
MethodCall (kMethodCallBlock)
Record of a function call that was invoked on a specific object.
| Payload | |||
|---|---|---|---|
| Field name | Type | Count | Details |
| api_call_id | APICallId | 1 | |
| object_id | u64 | 1 | Handle to the object this function call was invoked on. |
| thread_id | u64 | 1 | Uniquely identifies the thread that made the API call. |
| parameter_buffer | compressible_bytes | 1 | A sequence of bytes containing the serialized parameters for the API call. |
For the "separating payloads out" approach, are you thinking a table with block names that references another table of payloads?
Anything like that. I was thinking along the lines of either that or something else. Although you may have better ideas.