1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
//! Low-level `ash`/Vulkan renderer adapter for custom Damascene hosts.
//!
//! Use this crate when your application already owns an `ash` renderer
//! and wants to draw Damascene UI into its frame graph. The host remains
//! responsible for the Vulkan instance, physical device selection,
//! logical device, queues, command pools, command buffers, synchronization,
//! swapchain/surfaces, frame pacing, and platform event loop.
//!
//! The public entry point is [`Runner`]. Its surface intentionally
//! mirrors `damascene-wgpu` / `damascene-vulkano` where ash allows it: Damascene
//! owns interaction state and draw-op preparation; the host owns Vulkan
//! frame management.
//!
//! Rendering support is intentionally staged. Stock quad shaders, text,
//! raster images, flat MSDF icon/vector masks, and tessellated/painted
//! vectors are wired, and host-owned Vulkan textures can be composited
//! through [`app_texture`]. Backdrop sampling remains unsupported.
pub use ;
pub use ;
pub use ;
pub use PaintItem;
pub use ;
use vk;
/// Vulkan device features the ash runner's stock pipelines depend on.
///
/// Hosts should merge this into their own feature chain before creating
/// the logical device. For now this matches `damascene-vulkano`: sample-rate
/// shading is required once MSAA stock pipelines are enabled.
/// Vulkan 1.3 feature-chain requirements for the ash backend.
///
/// `damascene-ash`'s first rendering path uses dynamic rendering rather
/// than host-created render passes/framebuffers, so hosts creating a
/// Vulkan 1.3 device should include this in their `p_next` feature
/// chain. Hosts targeting older device APIs will need the equivalent
/// `VK_KHR_dynamic_rendering` extension path, which this crate does not
/// wrap yet.
/// Device extensions required by the renderer itself.
///
/// `damascene-ash` records rendering commands into host-owned command
/// buffers and does not create or present swapchains, so it has no
/// mandatory device extensions of its own. A Wayland/winit client host
/// usually still enables `VK_KHR_swapchain` for presentation.