READ BYTES · FRAME EVENTS · CONSUME
Streaming UX: time to first useful output
Fragment real encoded bytes, inspect the parser buffer and follow complete events into an ordered text consumer.
Text source and visible output
Appended output
Unparsed buffer: first 32 bytes in hex
Your experiment
Compare incremental consumption with full-body buffering under the same read interval. Measure the first appended output, not just receipt of the first byte.
The text is split into six-code-point deltas, numbered from 1. A source fault targets event 3, or the last event when fewer than three exist. Output is appended only after a complete frame is parsed and consumer processing finishes.
In streaming mode a full application queue pauses reads; one additional event may be processing. In buffered mode all body bytes arrive before parsing begins. The same 60-second inspection maps proportionally to each scenario’s modeled duration; it is not a network performance measurement.
Recent parser and consumer events
Original event fixtures
Offline byte-framing lesson. SSE parsing supports only the generated LF-delimited id/data subset; this is not a complete EventSource implementation. The alternative uses a zero compression byte plus four-byte big-endian payload length and UTF-8 JSON, not Protobuf. No HTTP/2 frames, headers, trailers, grpc-status, compression, TLS, provider API, A2A envelope, retries or reconnect/resume are implemented. The queue policy is application backpressure, not transport flow control. Duplicate suppression and strict contiguous event IDs are explicit application policies, not guarantees supplied by SSE/gRPC. Missing IDs are rejected without reordering or replay. Empty source is complete with no output; an incomplete frame remains truncated. SSE specification · gRPC message framing.
First bytes and first useful output are different events
The byte reader can receive data long before the user sees text. A complete frame must be available, its schema and sequence must be valid, queue space must exist, and the consumer must finish processing. The first-output counter records that final append event, not the first network-read timestamp. This is a local scheduler with synthetic timings, not a provider latency benchmark or a browser performance recording. It makes the sources of delay inspectable while preserving one fixed input across comparisons.
Control the byte and application boundaries
Local text supplies the payload, with the browser limiting entry to one hundred twenty UTF-16 code units. The model groups Unicode code points into records of up to six, each with a sequence identifier and delta string. Framing format selects the LF-delimited SSE subset or an uncompressed five-byte gRPC-style prefix around JSON. Application consumption either parses complete events incrementally or waits for the full body. Bytes per read changes fragmentation, Read interval changes scheduled arrival spacing, Processing per event changes consumer time, and Queued events bounds waiting records separately from the one active record. Parameter edits rebuild the scenario and start inspection unless reduced motion is requested.
Compare incremental and full-body policies fairly
Use sixty-four bytes per read, a one-hundred-millisecond read interval, one-thousand-millisecond consumer processing and one waiting queue slot. Record the complete-run preview for incremental consumption. Then switch only Application consumption to full-body buffering. The latter reads the whole body before parsing begins; compare first output and peak byte storage, not just final reconstructed text. Both policies can produce the same correct answer while exposing different waiting and buffering. Increase processing time to see why a faster reader cannot make a sequential consumer finish an event sooner.
Inject failures and inspect safely
Source event fault repeats, omits or corrupts the third event, or the last available event for a shorter source; truncation removes the final three wire bytes. Ignore already-applied event IDs affects duplicate records only. Missing or malformed records can leave a sequence gap, and later records are rejected rather than reordered or replayed. Play and Pause inspect sixty seconds of viewing time; Next event advances a recorded scheduler transition; Restart inspection rewinds; Speed adjusts viewing pace; Inspection time scrubs. Visible output, pending-byte hex and recent events reflect the inspected prefix. The complete-run preview and original event list describe the full scenario, not work already consumed.
Read the counters within their stated scope
Queued events excludes the one event being processed, while pending bytes excludes records already decoded. The peak byte count refers to the local parser buffer, not total application heap or socket memory. Read-paused time belongs to the application reader gate, not an observed TCP stall. Empty input has no first output, and a malformed first event can prevent useful text even when bytes arrive. Because each scenario maps its total modeled duration onto sixty viewing seconds, use the printed millisecond counters when comparing policies. The exercise does not model user attention, token generation time, cancellation or actual Java runtime scheduling.