import type { TSciChart } from "../../types/TSciChart";
import type { TSciChartSurfaceCanvases } from "../../types/TSciChartSurfaceCanvases";
import type { IThemeProvider } from "../Themes/IThemeProvider";
import type { I2DSurfaceOptions } from "./I2DSurfaceOptions";
import type { I3DSurfaceOptions } from "../../Charting3D/I3DSurfaceOptions";
import type { ISciChartSurfaceBase } from "./ISciChartSurfaceBase";
import type { TSciChartModuleName } from "./moduleLoader";
import type { ISciChartSurfaceOptions, TWebAssemblyChart } from "./SciChartSurface";
import { SciChartSurface } from "./SciChartSurface";
import { SciChartSurfaceBase } from "./SciChartSurfaceBase";
/**
 * Resolves the WebAssembly module factory. When wasm64 is enabled and supported, the self-contained
 * Memory64 module (scichart-64.js) is loaded via dynamic import so it stays out of the default bundle;
 * otherwise the standard wasm32 module is used.
 *
 * Union (one-wasm) build: the resolved module carries both the 2D and the 3D engine, so the whole
 * variant matrix is simd/nosimd x wasm32/wasm64 = 4 binaries, rather than the 8 a split 2D/3D build
 * would need. Absorbing wasm64 without doubling that matrix is part of why the module is unified.
 * @ignore Internal only - was accidentally auto-published by the export generator (Task 13, v6 API
 * cleanup); not part of the public API.
 */
export declare const resolveWasmModule2D: (useWasm64: boolean) => Promise<any>;
export type TSurfaceConstructor<T extends SciChartSurfaceBase> = (wasmContext: TSciChart, options?: ISciChartSurfaceOptions) => T;
/** @ignore Internal only - was accidentally auto-published by the export generator (Task 13, v6
 * API cleanup); not part of the public API. */
export type TExternalDestinationHandle = {
    unregister: () => void;
};
/**
 * What differs between a 2D and a 3D multi-chart child surface. 2D children are registered under
 * kind `"2d"` in the destination registry; 3D children render through SCRTSceneHost3D in the GUI
 * pass and register as *external* destinations, so they supply their own draw callback.
 *
 * Unlike {@link TSingleChartFamily} (createSingle.ts) this has no `kind` field: `createChildSurface`
 * branches on `drawFrame` alone, and the destination-kind reads/writes inside that branch
 * (`getDestinations("3d")`, `addDestination("3d", ...)`, etc.) are hardcoded literals under David's
 * 2026-07-30 verbatim-move ruling (task-12-brief.md Step 4), not derived from this type. A `kind`
 * field was tried and removed: wiring it through only the write site (`addDestination`) while the
 * orphan-pruning and dispose-gate reads stayed hardcoded to `"3d"` would decouple registration from
 * the reads that are supposed to observe it - worse than not wiring it at all. Do not re-add it
 * without also lifting the `"3d"` literals out of the verbatim-protected blocks in the same change.
 * @ignore Internal implementation detail of the family-descriptor pattern (Tasks 11-12); was never
 * intentionally public - surfaced in src/index.ts only because the generator had not been re-run
 * since it was added (Task 13 review).
 */
export type TMultiChartFamily<T extends SciChartSurfaceBase> = {
    surfaceConstructor: TSurfaceConstructor<T>;
    /** Undefined for 2D (the master draws it natively); supplied for 3D. */
    drawFrame?: (surface: T) => void;
    /**
     * A native wasm module `surfaceConstructor` cannot run without, in the modular build shape.
     * `createMultichart` awaits it after the shared engine exists and BEFORE `createChildSurface`,
     * which calls `surfaceConstructor` synchronously.
     *
     * An explicit declaration rather than an inference, and NOT the reinstated `kind` field this
     * type's own comment above forbids. Two alternatives were rejected:
     * - `family.drawFrame !== undefined`, the discriminator `createChildSurface` itself branches
     *   on. It happens to select the 3D family today, but it means "supplies its own draw callback
     *   for an external destination", which is not the same proposition as "needs the 3D engine
     *   dlopen'd first" - so a future external-destination 2D family would silently pay for a 1 MB
     *   module, and the requirement would be invisible at the declaration site.
     * - `kind: "3dSingle"` on the createSingle side. That discriminator exists, but nothing about
     *   the string says "this loads a wasm module", the coupling would live in createSingle.ts
     *   rather than beside the 3D surface it is about, and it would make the two creation paths use
     *   two different mechanisms for one concept.
     *
     * Declared once per family, next to the `surfaceConstructor` whose requirement it states. The
     * loud backstop for a family that forgets it is `SciChart3DSurface`'s own constructor guard
     * (`requireModule(...)`), which turns an "undefined is not a constructor" TypeError into a
     * named, actionable error.
     */
    requiresModule?: TSciChartModuleName;
};
/** @ignore */
type TSciChartMaster = {
    id: string;
    wasmContext: TSciChart;
    createChildSurface: <T extends SciChartSurfaceBase>(divElementId: string, canvases: TSciChartSurfaceCanvases, theme: IThemeProvider, family: TMultiChartFamily<T>) => T;
    getChildSurfaces: () => SciChartSurface[];
    registerExternalDestination: (canvasElementId: string, sciChartSurface: ISciChartSurfaceBase, onDraw: () => void) => TExternalDestinationHandle | undefined;
    /** Runs the native ClearDestinations()+re-add dance for callers (3D) that removed entries from
     *  the external-destination map but have no way to trigger the native resync themselves. */
    resyncDestinations: () => void;
};
/** @ignore */
export declare const createMultichart: <T extends SciChartSurfaceBase>(divElement: string | HTMLDivElement, family: TMultiChartFamily<T>, options?: I2DSurfaceOptions | I3DSurfaceOptions) => Promise<TWebAssemblyChart<T>>;
export declare const getSharedWasmContext: () => Promise<TSciChart>;
export declare const initializeChartEngine: (options?: {
    destinationCanvas: HTMLCanvasElement;
}) => Promise<TSciChartMaster>;
/**
 * @deprecated Since v6 one wasm module serves both 2D and 3D charts, so the `2D` suffix is
 * misleading. Use {@link initializeChartEngine}.
 */
export declare const initializeChartEngine2D: (options?: {
    destinationCanvas: HTMLCanvasElement;
}) => Promise<TSciChartMaster>;
/** @ignore */
export declare const disposeMultiChart: () => void;
/** @ignore */
export declare const monitorWebGL: (wasmContext: TSciChart, isMaster: boolean) => void;
export {};