- setting name column width is not the correct way, because this property is recursively supplied to the inner inspectors and hides what shouldn't be hidden
- proxying to the inner value overly complicates the implementation and adds a lot overhead
- this is quite dangerous change since it may have subtle side effects, needs to be thoroughly tested
* fix: eliminate UB in read_pixels_of_type via bytemuck::cast_slice
The previous implementation used Vec::from_raw_parts to reinterpret a
Vec<u8> as Vec<T>, then mem::forget to suppress the original Vec's
destructor. This was UB for two reasons:
1. mem::forget receives an invalid value (already-transferred ownership)
2. Vec<T> deallocates with align_of::<T>(), but the memory was allocated
with align_of::<u8>() = 1, violating alloc/dealloc layout invariants
Replace with bytemuck::cast_slice + to_vec(), which safely casts the
byte slice and copies into a properly-aligned Vec<T>. The Pod bound
already guarantees valid bit patterns for any byte sequence.
Closes#827
* fix: zero-copy TypedPixels<T> wrapper preserves original byte layout
Per @mrDIMAS review: avoid the .to_vec() copy by introducing a
TypedPixels<T> proxy struct that owns the original Vec<u8> (preserving
its allocation layout for correct deallocation) and exposes &[T] via
Deref + bytemuck::cast_slice. Mirrors the BytesStorage pattern used in
fyrox-impl/src/scene/mesh/buffer.rs.
The single caller (HDR luminance histogram) uses &pixels as a slice,
which works unchanged via deref coercion.
- previous impl was using ComponentProvider with a hacky impl that did unsafe transmute on a handle reference type
- new impl is using strong typing without type mangling
- previous approach with `ComponentProvider` trait was quite misleading, it didn't return a "component" - it simply returned marked fieds
- the new approach is more explicit - method names tells exactly what they do
Dmitry Stepanov