PCBUILD Archives

Personal Computer Hardware discussion List

PCBUILD@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
PCBUILD - Personal Computer Hardware discussion List <[log in to unmask]>
Date:
Wed, 4 Aug 1999 03:14:48 +0300
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
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]>

ATOM RSS1 RSS2