Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

u32 pixel color vs f32 #199

Closed
Alphapage opened this issue Feb 1, 2024 · 3 comments
Closed

u32 pixel color vs f32 #199

Alphapage opened this issue Feb 1, 2024 · 3 comments

Comments

@Alphapage
Copy link

Hello,

Why softbuffer provides u32 for the pixel color ?
Wouldn't it be better to provide f32 color to be aligned to gpu ?

Thank you in advance for your answers.

@madsmtm
Copy link
Member

madsmtm commented Feb 1, 2024

See also #98.

The u32 is actually roughly something like the following (probably depends on endianness):

#[repr(C)]
#[align(4)]
struct Color {
    reserved: u8,
    red: u8,
    green: u8,
    blue: u8,
}

So it doesn't actually have anything to do with the f32s that GPUs use.

@Alphapage
Copy link
Author

I thought it would be better to be able to have a vec4 of f32 buffer instead of having to convert vec4 f32 color to u32 at each pixel.
But it is strange that the api doesn't give a vec4 of f32 for color because gpu handles colors with a vec4 instead of the old RGBA of u8.
The buffer will increase a lot, so maybe it is more a performance problem and you prefer sacrify color precision in favour of speed.

@jackpot51
Copy link
Member

Most windowing systems use 8-bit per channel color when doing software rendering, which is why this crate exposes that. It would be a significant performance hit to use anything else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants