Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

24-bit color sucks

tiamat.tsotech.com

Post reply on HN
Print view View original

81–90 of 90 posts

Re: 24-bit color sucks

#81

Post by bhauer »

cromwellian wrote: post #24

It's overreach to say high DPI displays eliminate the need for anti-aliasing. You will still get shimmering, pixel popping, and temporal aliasing, it will just be harder to notice. If you have thin shapes like hanging cables or chain-link fences being displayed, even at high resolution, you will get pixels coming in and out of existence. Higher sampled AA tends to add spatial "stability" so that slight shifts of view…

Author here. You're right, high-DPI does not actually eliminate aliasing and I've toned done the wording slightly (added "nearly"). Certainly high-DPI is a huge step in the right direction even if several problems with aliasing remain.

I was simply attempting to say "thank you" to Apple for innovating with high-DPI displays so that I could follow that by saying more or less what you did: many things remain to address image clarity.

Re: 24-bit color sucks

#82

Post by bhauer »

ck2 wrote: post #20

What on earth is with all the motion on the website. Just because you can do animation doesn't mean you should.

Author here. You're completely right. I did for fun, not because I "should."

I'm not a designer; just someone who enjoyed playing with SVG and SMIL to make a subtle background effect that I liked.

You can turn off the animation with the menu at the bottom right. Apologies to everyone for burning your CPU cycles so needlessly. Just turn it off if you don't like it.

Re: 24-bit color sucks

#83

Post by bhauer »

kevingadd wrote: post #42

The number of bytes of memory available on GPUs is hardly the biggest issue when considering rendering at more than 8 bits per channel of color precision. Even producing a 30-bit framebuffer (as has been supported for a while on many desktop GPUs) comes at a performance penalty and is incompatible with many pieces of software and hardware. Modern GPUs actually allow 16 bits per channel of precision when rendering, bu…

You're right. I trivialize the challenges, and I admit that.

However, my point is that it has been some fifteen years since 24-bit "True Color" arrived. Certainly since then we've increased computing performance to the point where we can manage to throw a few more bits around, yes?

Also, you're right that browser vendors are dutifully concerned about performance. In fact, one of the reasons I enjoyed adding a subtly animated background (see previous reply apologizing to those who hate it) was a bit of evidence to back up another point I've made elsewhere: in 2012 our computers that process billions of CPU operations per second paired with high-powered GPUs can still get chunky with relatively trivial 2D animation in a web browser.

Incidentally, on that point, if you happen to have IE 10, check out how well it uses your GPU to do CSS transitions. It doesn't do the SVG/SMIL animation used in the background, but I find it fascinating how effortless it executes the animation it does support: http://tiamat.tsotech.com/ie-10-is-no-joke

I'd really like to see Chrome and Firefox catch up with that degree of GPU acceleration.

But in this particular blog entry, I'm asking that some attention return to rendering quality. I'd love to see color banding in gradients disappear soon.

Re: 24-bit color sucks

#84

Post by bhauer »

wildranter wrote: post #13
comex wrote: post #6

Earlier quoted context omitted.

It also lags down scrolling.

On the iPad it even blinks when scrolling. Though, it's a cool design.

Thanks for saying so, though I will admit I don't actually own an iPad and never tested the design there. Apologies to iPad users.

I aim to detect mobile browsers and just disable the background by default on mobile. (Incidentally, on the client side, is using Modernizr's "touch" flag a best practice here? I'm something of a noob.)

Re: 24-bit color sucks

#85

Post by bhauer »

mpyne wrote: post #78
mrspeaker wrote: post #25

Earlier quoted context omitted.

That's his point though, right: you are saying "meh, it's good enough".

It's always only good enough. Who actually has a literally perfect life?

True. Every step in technology's progress is selected because it's "good enough" to ship the technology out of the lab.

The point I'm making is this: it was good enough in ~1995. Frankly, it was awesome back then! But is it really still good enough in 2012?

Re: 24-bit color sucks

#86

Post by bhauer »

nairteashop wrote: post #18
yen223 wrote: post #7

Am I the only person who couldn't tell the difference in that horizontal gradient example?

Oddly enough, I can see it in Chrome but not in Safari. I'm on OS X.

Possible I have the gradients defined in such a way that Safari doesn't render it. Safari is supposed to pick up on the -webkit-linear-gradient, right?

background-image: linear-gradient(to left, #484848, #494949); background-image: -moz-linear-gradient(right, #484848, #494949); background-image: -webkit-linear-gradient(right, #484848, #494949);

Re: 24-bit color sucks

#87

Post by bhauer »

mrb wrote: post #37
devsatish wrote: post #29

With all due respect, I don't see the gradient break. may be because of that gray animation rotating behind that div?, this posts reminds me of that yesterday's HN parody.

Me neither. I can't see the gradient break. Not even after tweaking the brightness of my monitor. Edit: I can't see it because my config does automatic dithering. See my other posts.

mrb, I am envious of your configuration. If I could turn on system-wide dithering, I would do so in a heartbeat. You tempt me to ditch Windows even though I am (embarrassingly enough to admit here) actually fairly happy with Windows overall.

Re: 24-bit color sucks

#88

Post by kevingadd »

makomk wrote: post #53
kevingadd wrote: post #42

The number of bytes of memory available on GPUs is hardly the biggest issue when considering rendering at more than 8 bits per channel of color precision. Even producing a 30-bit framebuffer (as has been supported for a while on many desktop GPUs) comes at a performance penalty and is incompatible with many pieces of software and hardware. Modern GPUs actually allow 16 bits per channel of precision when rendering, bu…

As far as I know, most modern PC GPUs actually use a 32-bit framebuffer with 8 bits of padding for their 24-bit colour mode and do all shader computations in floating point already, so 30-bit colour isn't going to use any more memory bandwidth or shader time.

Doing 4 8-bit computations in parallel is different from doing 3 10-bit computations in parallel (or two 11-bit computations and one 10-bit computation). The hardware required is different.

Modern GPUs are certainly capable of high-precision arithmetic but it is not a safe assumption that all the hardware is designed for it. A lot of it is designed for the stuff it spends most of its time doing, which is 8 bits per channel rasterization.

Re: 24-bit color sucks

#89

Post by kevingadd »

snprbob86 wrote: post #69
kevingadd wrote: post #42

The number of bytes of memory available on GPUs is hardly the biggest issue when considering rendering at more than 8 bits per channel of color precision. Even producing a 30-bit framebuffer (as has been supported for a while on many desktop GPUs) comes at a performance penalty and is incompatible with many pieces of software and hardware. Modern GPUs actually allow 16 bits per channel of precision when rendering, bu…

> Modern GPUs actually allow 16 bits per channel of precision when rendering, but it comes at a significant cost - various features no longer function, memory bandwidth is devoured, etc. I'm not sure that this is true. It's extremely common for games to render lighting texture maps with HDR render targets. 16 bit-per-channel render targets are often used to accumulate excess light. The excess light gets processed by…

>8bpc render targets have limited feature sets, especially when talking about older architectures like the XBox 360.

It's true that they're used to accumulate lighting and other information, but that's basically one of the simplest possible use cases for a render target; you're just writing pixel data.

Multisampling, blending, etc - all things used often in 3D rendering - are not necessarily supported on a >8bpc render target. Whether you can do them depends on the drivers and the hardware. The same goes for textures that are >8bpc (filtering might not work, for example).

I ran into this problem just yesterday in a program I was writing when I tried to do blending on a high precision render target. :)

Re: 24-bit color sucks

#90

Post by jamesaguilar »

mrspeaker wrote: post #25
jamesaguilar wrote: post #23

Earlier quoted context omitted.

I could, but barely. Not enough that this website made me care about the issue.

That's his point though, right: you are saying "meh, it's good enough".

I'm saying that I'd love it if this was within the first thousand things on the list of biggest problems I'm dealing with.
Post reply on HN