/**
 * PanHowToOverlay — the "how to pan" coach-mark (guidance item 3).
 *
 * Shown briefly at the START of a capture to teach the panning
 * gesture before the live pan-speed pill (`PanoramaGuidance`) takes
 * over.  It pairs the code-drawn `PanPhoneGraphic` (white phone +
 * sweeping amber band) with a code-built bouncing arrow so the
 * direction reads instantly without any copy.
 *
 *   ┌──────────────────────────────────────────────────────────┐
 *   │                                                          │
 *   │                  ┌───────────────┐                       │
 *   │                  │  PanPhone     │   (240px graphic, the │
 *   │                  │  Graphic      │    white phone +      │
 *   │                  └───────────────┘    amber sweep)       │
 *   │                         ▼  ← amber triangle              │
 *   │                         ▼     bouncing ~12px along the   │
 *   │                              pan axis, back and forth    │
 *   └──────────────────────────────────────────────────────────┘
 *
 * Direction follows the capture mode (derived from the physical
 * device orientation, sensor-based — works under portrait-lock):
 *
 *   Mode A — LANDSCAPE  → pan TOP → BOTTOM → arrow points DOWN.
 *   Mode B — PORTRAIT   → pan LEFT → RIGHT → arrow points RIGHT.
 *
 * Both `landscape-left` and `landscape-right` are valid Mode A.
 *
 * ## Visibility & timing
 *
 * This component is intentionally pure-presentational: the PARENT
 * owns `visible` and the brief auto-fade lifecycle (mount → show →
 * dismiss once recording is under way).  We never self-time;
 * `visible === false` renders `null` so the host can mount us
 * unconditionally without layout shift.
 *
 * ## Upright under portrait-lock
 *
 * The app layout is typically portrait-locked, so when the user
 * holds the device in landscape (Mode A) the JS framebuffer is NOT
 * rotated.  We counter-rotate the whole coach-mark with
 * `useContentRotation()` (same hook the bottom controls use) so the
 * graphic and arrow read upright relative to gravity.  The arrow's
 * bounce axis and triangle point are expressed in that upright frame
 * — i.e. the user's view — so "down" / "right" mean what the user
 * sees, not the layout's raw axes.
 *
 * ## No SVG / no extra deps
 *
 * The arrow is a pure CSS border-width triangle (a zero-size View
 * whose thick coloured border on one edge + transparent borders on
 * the adjacent edges read as a filled triangle).  Bounce is a single
 * `Animated.loop` on the native driver — cheap, and only running
 * while `visible`.
 */
import React from 'react';
import { type StyleProp, type ViewStyle } from 'react-native';
import { type DeviceOrientation } from './useDeviceOrientation';
export interface PanHowToOverlayProps {
    /**
     * Show / hide.  `false` renders `null`.  The host owns the brief
     * auto-fade lifecycle — this component never self-times.
     */
    visible: boolean;
    /**
     * Physical device orientation (sensor-based, from
     * `useDeviceOrientation`).  Selects the pan mode → arrow
     * direction: landscape-* → DOWN (Mode A), portrait-* → RIGHT
     * (Mode B).
     */
    orientation: DeviceOrientation;
    /** Outer style passthrough (positioning / opacity from the host). */
    style?: StyleProp<ViewStyle>;
}
export declare function PanHowToOverlay({ visible, orientation, style, }: PanHowToOverlayProps): React.JSX.Element | null;
//# sourceMappingURL=PanHowToOverlay.d.ts.map