RGB mixup... What were MS thinking?!?
Hello,
This is sort of a discussion I just needed a way to express my anger when i found out that:
In windows GDI a RGB color is defined like a 32 bit value with first eight bits zero second eight blue third green and finally red or in c++ terms:
(b<<16) | (g<<8) | (r)
and that's ok. Who cares... aparantly it was easier
But! When writing directly to video memory to get the same color you should change the places of blue and red like that
(r<<16) | (g<<8) | (b)
:sick: :eek:
That means that it was not easier. That means that internally windows reverses each color bit before sending it to the video device. Why that? It is slower and it has got no sense in it!!
And if a devloper tries to do something receiving colors from windows and using them in a DirectX application he should change each color, and viceversa... Not that is a significan problem but my question is WHY?!?!?! Who needed this color reversing in Windows?
:confused: :confused: :confused: :confused:
# 1 Re: RGB mixup... What were MS thinking?!?
Writing directly to whose video memory? 3dfx? NVidia? Also, what about color printers? How do they store RGB values?
Also the GDI was thought up back in Windows 3.1 (remember DOS). I don't recall, but it's possible that the video cards at the time used BGR (when going to 16/24 bits) values. And since GDI has to remain somewhat backward compatible, the current GDI still uses BGR.
Viggy
# 2 Re: RGB mixup... What were MS thinking?!?
This problem is often seen when the PCI card manufacturer uses a chip that has opposite endian-ness (yes, I know endian-ness is not a word) than the host computer's CPU. 0x86 chips are littel-endian. If the graphics card is a big-endian chip, then the order of the values will need to be reversed. If the GPU is little-endian, then you likely don't have to deal with the problem. I have personally dealt with this many times in my career.
So in effect, it's the graphic card manufacturer's fault just as much as Intel's and just as much as Windows. But even then the graphics card manufacturer can't play it 100% safe, because there are other CPUs that are big-endian: Macintosh (well for the next 6-18 months anyway), Sun Solaris, etc... So someone is obviously going to be pissed off either way. However, in my opinion, companies should know that Windows own 95+% market share and should aim to make their cards easier (and faster) to use on that platform. Oh well!
# 3 Re: RGB mixup... What were MS thinking?!?
Macintosh (well for the next 6-18 months anywayKevin, what do you mean by this?
Arjay
Arjay at 2007-11-9 12:19:12 >
# 4 Re: RGB mixup... What were MS thinking?!?
Haven't you been listening to the news? Apple has decided to switch from the PowerPC chips to Intel chips. I'm not completely sure of the timeframe -- my 6-18 month timeline may be a little off. But since Macs will be using Intel, that means almost all desktop computers will be using 0x86 - based chips, and consequently will all have little-endian CPUs.
# 5 Re: RGB mixup... What were MS thinking?!?
Haven't you been listening to the news?Apple news isn't particularly high up on my priority list. Thanks for the info.
Arjay at 2007-11-9 12:21:15 >
# 6 Re: RGB mixup... What were MS thinking?!?
Apple news isn't particularly high up on my priority list. Thanks for the info.
You must not live in the US. My wife is *NOT* into computers, but even she noticed all talk about it in the US. It's a big deal over here.
# 7 Re: RGB mixup... What were MS thinking?!?
You must not live in the US. My wife is *NOT* into computers, but even she noticed all talk about it in the US. It's a big deal over here.
Oh, yeah! This implies that an Apple desktop might possibly run the Windows OS. And, I can run MacOS on my PC at home!
;)
Viggy
# 8 Re: RGB mixup... What were MS thinking?!?
Try GDI+. Or DirectX.
In both these technologies which parts of the pixel are used for which RGBA values.
Also this (as already been said) depends on the card manufacturer.
In the case of DirectX you can query the system to find out what colour model the card is using.
With the Win32 based bitmaps there is still a problem.
But to be honest, it's not too difficult to write a piece of code to determine which bits of a pixel are used for any particular colour - even going down to 16-bit.
It's never been a problem for me... my code to decide how to treat RGBA values is in a library I just add to whichever VC++ application which needs to use it.
Hey - here's a thought - use object orientation to "code share" and never have to write the same piece of code twice. Hey that's new isn't it ? :eek:
Darwen.
darwen at 2007-11-9 12:24:10 >
