From 4df5bc6307dc15a36e9ebc16be8d7ad10a803e35 Mon Sep 17 00:00:00 2001 From: Andreas Reich Date: Tue, 8 Oct 2024 18:13:22 +0200 Subject: [PATCH] typo fixes --- .../src/resource_managers/chroma_subsampling_converter.rs | 2 +- .../src/resource_managers/image_data_to_texture.rs | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/crates/viewer/re_renderer/src/resource_managers/chroma_subsampling_converter.rs b/crates/viewer/re_renderer/src/resource_managers/chroma_subsampling_converter.rs index 0327c3fe65ad..23f10daf2fb8 100644 --- a/crates/viewer/re_renderer/src/resource_managers/chroma_subsampling_converter.rs +++ b/crates/viewer/re_renderer/src/resource_managers/chroma_subsampling_converter.rs @@ -189,7 +189,7 @@ impl ChromaSubsamplingConversionTask { ) -> Result { // TODO(andreas): Does this have to be on the global view encoder? // If this ever becomes a problem we could easily schedule this to another encoder as long as - // we gurantee that the conversion is enqueued before the resulting texture is used. + // we guarantee that the conversion is enqueued before the resulting texture is used. // Given that we already have this neatly encapsulated work package this would be quite easy to do! let mut encoder = ctx.active_frame.before_view_builder_encoder.lock(); let mut pass = encoder diff --git a/crates/viewer/re_renderer/src/resource_managers/image_data_to_texture.rs b/crates/viewer/re_renderer/src/resource_managers/image_data_to_texture.rs index 107691dc8808..5e5b27f89cc9 100644 --- a/crates/viewer/re_renderer/src/resource_managers/image_data_to_texture.rs +++ b/crates/viewer/re_renderer/src/resource_managers/image_data_to_texture.rs @@ -11,7 +11,7 @@ use crate::{ /// /// This applies both to YUV and RGB formats, but if not specified otherwise /// we assume BT.709 primaries for all RGB(A) 8bits per channel content (details below on [`ColorSpace::Bt709`]). -/// Since with YUV content the color space is often less clear, we always explicitely +/// Since with YUV content the color space is often less clear, we always explicitly /// specify it. /// /// Ffmpeg's documentation has a short & good overview of these relationships: @@ -189,7 +189,7 @@ impl<'a> ImageDataDesc<'a> { /// /// Schedules render passes to convert the data to a samplable textures if needed. /// -/// Generally, we currently do *not* sRGB converting formats like [`wgpu::TextureFormat::Rgba8UnormSrgb`] in order to... +/// Generally, we currently do *not* use sRGB converting formats like [`wgpu::TextureFormat::Rgba8UnormSrgb`] in order to… /// * have the same shader code path for high precision formats (e.g. an f16 texture that _still_ encodes sRGB data) /// * handle alpha pre-multiply on the fly (needs to happen before sRGB decode to linear) ///