high level design

FrameRetrace is split into 2 processes, communicating over a socket with a well-defined interface. The UI is the client, which makes calls to the frame_retrace_server, which may be running on a remote system.

The server interface is defined at retrace/daemon/glframe_retrace_interface.hpp Look for the IFrameRetrace class.

Each call to IFrameRetrace may generate a callback to one of the methods in OnFrameRetrace. For example, the UI will invoke retraceRenderTarget(), and the server will invoke onRenderTarget() for each render target in the selection.

UI process <----> IFrameRetrace <----> server process

The RPC for IFrameRetrace is implemented with Google protocol buffers. The UI calls a "stub", which encodes the request in protobuf and sends the message over the socket. A "skeleton" thread is reading protobuf messages from the socket on the server side. The skeleton decodes the message parameters, and invokes the IFrameRetrace method in the server, passing its own reference as the callback. When a callback is made on the skeleton, the data is encoded in a protobuf message, and written back to the socket.

On the client side, the stub is reading the socket to get the protobuf response. The stub decodes the response and makes the callback in the UI.

So a call to IFrameRetrace follows this chain of control:

UI process <--> stub <--> protobuf-via-socket <--> skeleton <--> server process

The protobuf messages are defined in retrace/daemon/playback.proto The skeleton/stub classes are in retrace/daemon/glframe_retrace_skeleton.hpp and retrace/daemon/glframe_retrace_stub.hpp

UI design

server design

IFrameRetrace