#[repr(C)]pub struct Quad {
pub rect: Rect,
pub color: Color,
pub border_color: Color,
pub radius: [f32; 4],
pub border_w: f32,
pub blur: f32,
pub kind: QuadKind,
pub clip: ClipId,
pub uv: [u32; 4],
}Fields§
§rect: RectPhysical pixels.
color: Color§border_color: Color§radius: [f32; 4]Corner radii in physical pixels, clockwise from the top-left:
[tl, tr, br, bl].
border_w: f32§blur: f32QuadKind::Shadow only: the blur radius in physical pixels, which
is also how far rect is inflated past the shape being blurred.
Zero elsewhere.
kind: QuadKind§clip: ClipIdWhich entry of DisplayList::clips clips this quad: pixels
outside that rect — and outside its rounded corners, when it has
any — are discarded.
An index rather than the clip itself because a clip is thirty-two
bytes and a frame has a handful of them: every quad under one card
names the same entry, and a frame that clips nothing names one
entry from every quad it has. Carrying the rect and its four radii
on the quad cost 32 of the 124 bytes each, on a struct written once
per quad and then walked again by the fade pass, the backend’s
upload and the previous frame depart keeps. The same reasoning
put a fragment’s parameters in DisplayList::fragments.
uv: [u32; 4]Atlas texels: x, y, w, h. For QuadKind::Segment the two
endpoints instead, as f32 bits (see Quad::segment_ends).
Implementations§
Source§impl Quad
impl Quad
Sourcepub fn segment_ends(&self) -> [f32; 4]
pub fn segment_ends(&self) -> [f32; 4]
A QuadKind::Segment’s endpoints, [x0, y0, x1, y1] in physical
px, decoded from the bits uv carries. Meaningless for any other
kind.
Sourcepub fn segment_uv(ends: [f32; 4]) -> [u32; 4]
pub fn segment_uv(ends: [f32; 4]) -> [u32; 4]
The uv a QuadKind::Segment carries for these endpoints.