fixed the readmes

README.md

@@ -8,7 +8,7 @@ classification, dewarping, and table-structure recognition — for the
 [React Native ExecuTorch](https://www.npmjs.com/package/react-native-executorch) library,
 fused into **one multi-method `.pte`** per backend for the **ExecuTorch** runtime
 (XNNPACK, CoreML, Vulkan). These are document pre/post-processing companions to
-[`react-native-executorch-paddleocr`](https://huggingface.co/software-mansion/react-native-executorch-PP-OCRv6) -
+[`react-native-executorch-pp-ocrv6`](https://huggingface.co/software-mansion/react-native-executorch-pp-ocrv6) —
 not an OCR model on their own.
 
 If you'd like to run these models in your own ExecuTorch runtime, refer to the
@@ -17,7 +17,9 @@ If you'd like to run these models in your own ExecuTorch runtime, refer to the
 ## Methods
 
 The fused `.pte` exposes **four methods** (the `.pte` is pure tensor→tensor; the client
-does normalization, `argmax`/`softmax`, grid-sampling and the decode loop):
+does normalization, `argmax`/`softmax`, grid-sampling and the decode loop). All methods are
+**fixed-shape** — the exact input shapes below are also declared in `config.json`; there are
+no shape-discovery companion methods on this model.
 
 | method | source model | input | output | purpose |
 |---|---|---|---|---|
@@ -26,16 +28,18 @@ does normalization, `argmax`/`softmax`, grid-sampling and the decode loop):
 | `table_encode` | [SLANeXt](https://huggingface.co/PaddlePaddle/SLANeXt_wired_safetensors) | `[1,3,488,488]` | `feat[1,256,96]` | encode a cropped table image (run **once**) |
 | `table_decode_step` | SLANeXt decoder | `(feat[1,256,96], hidden[1,256], onehot[1,50])` | `(probs[1,50], hidden[1,256])` | one **autoregressive** structure-token step |
 
-## Backends & precision
-
-| backend | target | precision | size |
-|---|---|---|---|
-| `xnnpack` | CPU | **int8** | ~26 MB |
-| `coreml` | Apple ANE | weight-only int8  | **11.9 MB** |
-| `vulkan` | Android GPU | fp16, except `table_decode_step` → XNNPACK  | 23.9 MB |
-
-`table_decode_step` is always computed in fp32 (autoregressive stability)
+## Backends, precision & latency (warm)
 
+| backend | target | precision | size | orientation / table_encode / dewarp / decode_step |
+|---|---|---|---|---|
+| `xnnpack` | CPU | **dynamic int8** (qd8 — lossless; static int8 is lossy on the regressors) | ~28 MB | 2.0 / 30 / 209 / 0.21 ms (Galaxy S24) |
+| `coreml` | Apple ANE | weight-only int8 | **11.9 MB** | 0.3 / 1.4 / 4.7 / 0.13 ms (Apple M-series ANE) |
+| `vulkan` | Android GPU | fp16, except the table path → XNNPACK (mixed-delegate) | 23 MB | 6.0 / 17 / 66 / 0.21 ms (Galaxy S24) |
+
+- The GPU wins on the heavy CNNs (dewarp 3×); the tiny `orientation` and the dispatch-bound
+  autoregressive `table_decode_step` are faster on CPU — hence the Vulkan build routes the
+  table path to XNNPACK.
+- `table_decode_step` is always computed at full precision on CPU (autoregressive stability).
 
 ## Compatibility