Are We Stuck At 16Bit Graphics?


Joined
May 17, 2010
Messages
2,198
Location
:|
I noticed ever since I first used the Pandora that the display seems to be less than 32bit (colour banding etc.).

I always assumed this was a software thing, like maybe an XFCE setting that would be fixed later. What confused me was that the Gamma settings have options for 32bit, but it doesn't seem to change anything.

I just read elsewhere on the forums that the Pandora only has a 16bit display. Is this true?
 
SomeGuy99 said:
I noticed ever since I first used the Pandora that the display seems to be less than 32bit (colour banding etc.).

I always assumed this was a software thing, like maybe an XFCE setting that would be fixed later. What confused me was that the Gamma settings have options for 32bit, but it doesn't seem to change anything.

I just read elsewhere on the forums that the Pandora only has a 16bit display. Is this true?

xfce runs in 16 bpp, 32 bpp is/will be possible, but I cant recall if it was ready yet
 
Last edited by a moderator:
Where did you read this?

I can't saw authoritatively right now, but a 16-bit LCD would be very strange, given that most over the past several years are at least 18-bit - even Nintendo DS's. For this size and resolution I'd definitely expect full 24-bit. According to the Pandora Hacker's Manual the LCD connector is at least 24-bit, so the LCD most likely is.

The display controller on Pandora can definitely output 24-bit as well, this I can tell you with full confidence. If you can't use it it might be a matter of driver support in the X drivers. I think the DSS2 drivers might currently only support 16-bit as well.
 
Pickle said:
SomeGuy99 said:
I noticed ever since I first used the Pandora that the display seems to be less than 32bit (colour banding etc.).

I always assumed this was a software thing, like maybe an XFCE setting that would be fixed later. What confused me was that the Gamma settings have options for 32bit, but it doesn't seem to change anything.

I just read elsewhere on the forums that the Pandora only has a 16bit display. Is this true?

xfce runs in 16 bpp, 32 bpp is/will be possible, but I cant recall if it was ready yet

Ah ok, cheers. :)
 
Last edited by a moderator:
KodeIn said:
iampanis said:
The LCD's datasheet says that it supports 16 million colors.
Great, 24bpp will give even smoother gradients \o/
Friggin' great screen we have there.
Excellent, so basically all the colors that a typical monitor will do. I assume that means that the entire 32bpp are available, given that the remainder is just alpha.
 
Last edited by a moderator:
Pickle said:
xfce runs in 16 bpp, 32 bpp is/will be possible, but I cant recall if it was ready yet

How about minimenu? Will 32bpp ever be possible there?
 
Last edited by a moderator:
notaz said:
For a test, open terminal and type 'op_gammatool' and press Y when the app appears.
app runs;see the screen with all the pretty colors, but pressing Y does not change the color depth.
 
Last edited by a moderator:
Lobo said:
app runs;see the screen with all the pretty colors, but pressing Y does not change the color depth.
Y as in the game button Y (upmost), works for me?
 
Last edited by a moderator:
A Retro Console don't need 32 Bit (game) Graphics. ;)

If 32bpp means less performance (and I bet it means this :D ) I will keep maximum of 16bpp happily. I even would use 256 Colours for menus if this would bring more speed and if the skins are optimized for this. ;)
 
fusion_power said:
A Retro Console don't need 32 Bit (game) Graphics. ;)

If 32bpp means less performance (and I bet it means this :D ) I will keep maximum of 16bpp happily. I even would use 256 Colours for menus if this would bring more speed and if the skins are optimized for this. ;)
The pandora is not just a Retro Console, it's meant to have its own original games, so 32bpp is a desirable option.
 
Last edited by a moderator:
As stated above 32bpp is 24bpp word aligned.
For Xorg (linux graphical environnement) setting 32 as depth will be effectivly treaded as 24.
Actually xorg.conf state depth=16, and without xrandr not app will change this dynamicaly. so minimenu is as 16bpp as the rest.
If OPT could have set this to 24, they would have done it, so I'm going with exo guess : driver limitation
 
fusion_power said:
A Retro Console don't need 32 Bit (game) Graphics. ;)

If 32bpp means less performance (and I bet it means this :D ) I will keep maximum of 16bpp happily. I even would use 256 Colours for menus if this would bring more speed and if the skins are optimized for this. ;)

Hmm. Usually, 32bpp graphics are more efficient than 16bpp, especially on a 32bit processor - assuming you're not using hardware acceleration, that is. Mind you, 16bpp (while not as efficient in as 32bpp in many repects) can be more efficient than 24bpp, especially when banging rows of pixels around the screen.

D.
 
Last edited by a moderator:
sebt3 said:
As stated above 32bpp is 24bpp word aligned.
For Xorg (linux graphical environnement) setting 32 as depth will be effectivly treaded as 24.
Actually xorg.conf state depth=16, and without xrandr not app will change this dynamicaly. so minimenu is as 16bpp as the rest.
If OPT could have set this to 24, they would have done it, so I'm going with exo guess : driver limitation
Admittedly, I could be wrong, but I thought those extra 8 bits were used for alpha. Or is that just when it comes to graphics utilities as the extra bits aren't really being used anyways.

EDIT: 8 for red, 8 for green, 8 for blue and 8 for alpha.
 
Last edited by a moderator:
Dunny said:
Hmm. Usually, 32bpp graphics are more efficient than 16bpp, especially on a 32bit processor - assuming you're not using hardware acceleration, that is. Mind you, 16bpp (while not as efficient in as 32bpp in many repects) can be more efficient than 24bpp, especially when banging rows of pixels around the screen.

D.

32bpp will almost never be more efficient than 16bpp. Most 32-bit CPUs have the ability to to write individual 16bit words, and writes to areas like video memory are usually write buffered and often write combining (are in the case of Cortex-A8). So with 16bpp you don't have any overhead and you have a lower memory bandwidth footprint both in writing the framebuffer and for the display controller to read it, lower cache utilization for anything intermediate too. The difference will be minor though.

The only area in which 32bit may be more efficient is in doing pixel math using SIMD, since the channels align better with the vector words. But this is often negated again by higher data density.. all depends on how the operations are laid out.

hedwards said:
Admittedly, I could be wrong, but I thought those extra 8 bits were used for alpha. Or is that just when it comes to graphics utilities as the extra bits aren't really being used anyways.

EDIT: 8 for red, 8 for green, 8 for blue and 8 for alpha.

A display doesn't usually have any use for an alpha channel. Framebuffers may have alpha bits if a renderer is using destination alpha for alpha blending operations. Also may have them if they're overlaid in hardware with per-pixel blending.
 
Last edited by a moderator:
Back
Top