Sender: |
|
Date: |
Wed, 4 Aug 1999 03:14:48 +0300 |
MIME-version: |
1.0 |
Reply-To: |
|
Content-type: |
text/plain; charset=US-ASCII |
Subject: |
|
From: |
|
In-Reply-To: |
|
Content-transfer-encoding: |
7BIT |
Parts/Attachments: |
|
|
On 2 Aug 99, at 17:47, Dave Gillett <[log in to unmask]> wrote:
> > 3) If I am right then how this goes with 16 or 32bit color? 32 and 16
> > are not a multiplicity of 3.
>
> 16-bit coulour typically uses 5 bits each of red/green/blue (that's 15
> total), luse one for "intensity".
> 32-bit colour is generally 8 bits each of red/green/blue (that's 24 --
> that's about as fine a gradation of colours as the human eye can
> distinguish), but pixels are aligned on 32-bit boundaries rather than
> 24-bit boundaries -- this greatly simplifies I/O between CPU and video
> buffer, improving performance of the video subsystem.
That's striking !
Just let me make sure I understand the scoop in it:
If you'de ask me two days ago about changing from 24 bit color to 32 bit
color, I would have NAIVELY said: "changing from 24bit to 32bit will
improve quality (more bits to define color) on account of speed (more
bits should be delivered per point). In other words switching to 32bit will
improve quality but will reduce speed".
Now, according to what you say, on standard systems, it will not
improve quality, but will improve speed ! (I interpret performance as
speed) - almost the opposite from the naive interpretation.
Uzi
PCBUILD's List Owner's:
Bob Wright<[log in to unmask]>
Drew Dunn<[log in to unmask]>
|
|
|