docs: Add comprehensive MCP architecture design for GUI graph editor - #6
Open
Lint111 wants to merge 4 commits into
Open
docs: Add comprehensive MCP architecture design for GUI graph editor#6Lint111 wants to merge 4 commits into
Lint111 wants to merge 4 commits into
Conversation
Add three detailed documentation files outlining the Model-Controller-View architecture for transforming the RenderGraph system into a GUI graph editor: 1. MCP_Architecture_Design.md - Complete MVC layer separation (Model/Controller/View) - 8 Model components (GraphModel, NodeModel, ConnectionModel, etc.) - 8 Controller components with command pattern + undo/redo - 6 View components for interactive editing - Implementation phases and technology recommendations 2. MCP_Implementation_Example.md - Concrete C++ implementations of NodeModel, NodeController, NodeView - Command pattern implementation with undo/redo - Observable pattern for automatic UI synchronization - Complete workflow examples (create node, connect, compile, execute) 3. Node_Config_To_Controller_Mapping.md - Transformation pipeline: compile-time config → runtime descriptor - Registry-based controller points for all 45+ node types - Type compatibility rules and validation logic - Auto-generation tools for config-to-descriptor translation - Examples: WindowNode, ComputePipelineNode transformations Key architectural principles: - Model: Single source of truth, wraps RenderGraph with observables - Controller: Command pattern, validation, orchestration - View: Passive rendering, observes model changes - Zero overhead: No performance penalty on existing RenderGraph - Type safety: Compile-time + runtime validation preserved This architecture enables full GUI graph editing while maintaining the existing type-safe, zero-overhead RenderGraph system.
Add new architecture document that demonstrates building the graph editor application using RenderGraph nodes themselves, creating a self-hosting meta-circular design. Key improvements over traditional MVC approach: - Core RenderGraph stays pure (no GUI/MVC dependencies) - Editor is built AS a RenderGraph application - MVC pattern emerges from node categories: * Model nodes: GraphStateNode, NodeRegistryNode, SelectionNode * View nodes: NodeRendererNode, ConnectionRendererNode, UIRendererNode * Controller nodes: InputHandlerNode, CommandProcessorNode, ValidationNode Benefits: ✓ Self-hosting: framework edits itself ✓ No framework pollution: MVC only in editor app, not core ✓ Composability: mix/match editor features as nodes ✓ Same tools: debug/profile editor like any graph ✓ Extensibility: add features by adding nodes Example node types: - GraphStateNode: stores graph being edited (model) - NodeRendererNode: renders nodes visually (view) - CommandProcessorNode: processes user actions (controller) - ValidationNode: validates connections in real-time - GraphCompilerNode: compiles edited graph to executable RenderGraph - GraphSerializerNode: saves/loads graphs to JSON Complete data flow example shows how dragging a node from palette flows through InputHandler → CommandProcessor → UndoRedo → GraphState → NodeRenderer. This is the elegant approach: the graph editor is itself a graph.
…ditor Add comprehensive analysis of the fundamental architectural transformation needed to build a graph editor using RenderGraph nodes. Core Insight: To use RenderGraph to build a graph editor, we need a two-level architecture where graphs can be both runtime orchestrators AND data structures: - Level 1 (Runtime): Editor application graph using RenderGraph as orchestrator - Level 2 (Data): Graph being edited as data structures flowing through Level 1 Key Transformation: Before: RenderGraph is orchestrator - AddNode(), ConnectNodes() are methods ON the graph - Can't represent "add node" as a node itself After: Graph operations become nodes operating on graph data - GraphData struct: nodes, connections, metadata (pure data) - AddNodeToGraphNode: transforms GraphData (adds node to structure) - GraphCompilerNode: transforms GraphData → RenderGraph instance New Data Structures: - GraphData: Lightweight representation of graph structure - NodeDescriptor: Node type, instance name, parameters, position - ConnectionDescriptor: Source/target nodes, slots, connection type New Operation Nodes: - AddNodeToGraphNode: Add node to graph data - ConnectNodesInGraphNode: Add connection to graph data - RemoveNodeFromGraphNode: Remove node from graph data - ValidateGraphNode: Validate graph structure and types - GraphCompilerNode: Compile GraphData → executable RenderGraph - SerializeGraphNode: GraphData → JSON - GraphStateNode: Manages current graph data with command processing Benefits: ✓ Pure functional transformations (input graph → output graph) ✓ Undo/redo for free (store old GraphData) ✓ Multiple graphs simultaneously (no singleton orchestrator) ✓ Self-hosting (editor can load and modify its own graph) ✓ Clear separation (RenderGraph unchanged, GraphData new, Editor nodes new) ✓ Composable operations (chain graph transformations) Migration: Core RenderGraph unchanged, add GraphData structures and operation nodes in new RenderGraphEditor library. This is the fundamental refactoring required to achieve meta-circular graph editing where the editor is built using the framework it edits.
…ation
Document the three-layer architecture that enables node-based graph
manipulation without duplicating logic between RenderGraph methods and
operation nodes.
Architecture Layers:
1. Data Layer: GraphData (pure structures - nodes, connections, metadata)
2. Operations Layer: GraphOperations namespace (shared logic)
3. Interface Layers:
- RenderGraph methods (orchestrator API)
- Operation nodes (data flow API)
Key Insight: Extract core graph manipulation logic into shared functions
that BOTH RenderGraph methods AND operation nodes call.
Example flow:
RenderGraph::AddNode() → GraphOperations::AddNode() ← AddNodeToGraphNode::Execute()
↓
GraphData
Zero Duplication Strategy:
- GraphOperations::AddNode(GraphData&, NodeDescriptor) - single implementation
- RenderGraph::AddNode<T>() calls GraphOperations::AddNode() internally
- AddNodeToGraphNode::Execute() also calls GraphOperations::AddNode()
- Same logic, two interfaces (imperative vs data flow)
Core Operations Extracted:
✓ AddNode() - validation, duplicate checking, add to graph
✓ RemoveNode() - remove node and cascade delete connections
✓ ConnectNodes() - type validation, duplicate checking
✓ ValidateGraph() - cycle detection, required slot checking
✓ HasCycles() - DFS-based cycle detection
✓ CompileToRenderGraph() - transform GraphData → RenderGraph instance
What Stays in RenderGraph:
✓ Runtime state (NodeInstance ownership, execution order)
✓ Resource allocation (VkImage, VkBuffer creation)
✓ Vulkan pipeline compilation
✓ Execution scheduling and synchronization
What's Extracted to GraphOperations:
✓ Graph structure manipulation (add, remove, connect)
✓ Validation logic (cycles, types, required slots)
✓ Serialization/deserialization
Benefits:
✓ Zero logic duplication (single source of truth)
✓ Backward compatible (existing RenderGraph API unchanged)
✓ Testable (pure functions in GraphOperations)
✓ Flexible (use RenderGraph, nodes, or operations directly)
✓ Clear separation (data vs runtime vs operations)
Migration phases defined with checklist for extracting operations
from RenderGraph while maintaining full backward compatibility.
Lint111
added a commit
that referenced
this pull request
Jul 13, 2026
Features #4/#5/#6, the program's flagged-HARDEST increment. Research refines the risk: not algorithmic (formulaic dispatch tables over Increment 5's already-solved Field IR), but blast-radius + verification cost against an 81-version binary wire format with zero structural self-description within a record. Found codec-golden.b64 (the only automated equivalence oracle) is currently 0 bytes in this checkout -- added as a mandatory Task 0 pre-flight before any porting starts.
Lint111
added a commit
that referenced
this pull request
Jul 13, 2026
…MPLETE Hardest increment in the program done: all 3 sub-milestones (2a codec, 2b merge, 2c patch-parser) built, byte-identical equivalence proven for all 3 generated files via independent from-scratch re-derivation, end-to-end parse-then-merge cross-check confirms #4/#5/#6 cohere as one system. Full retirement of all 6 generator files + 33 obsolete Roslyn-internal test cases. 2922/2922 undertow tests pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add three detailed documentation files outlining the Model-Controller-View
architecture for transforming the RenderGraph system into a GUI graph editor:
MCP_Architecture_Design.md
MCP_Implementation_Example.md
Node_Config_To_Controller_Mapping.md
Key architectural principles:
This architecture enables full GUI graph editing while maintaining the
existing type-safe, zero-overhead RenderGraph system.