Hi Mathias, Even I'm facing the same problem with ARGB_32 format. My hardware expects BGRA_32 format i.e. A(32-24)R(24-16)G(16-8)B(8-0) bits and surface is also created with this format.. But I see the PIXEL_FORMAT_ARGB_8888 in the format.cpp with Red and Blue bits swapped like A(32-24)B(24-16)G(16-8)R(8-0).
I swap the red and blue bytes of the pixel data before creating my texture.When I launch my application which shows the all the running applications in a small window, a proper yellow texture or tinted window through which I see my icons as in case of when we select icons from menu. As I'm doing shifting and ORing operation on every 4 bytes of pixel data, the system is getting really slow and I believe its not a right way to do. Isn't it ? In format.cpp , for the pixel format GGL_PIXEL_FORMAT_ARGB_8888 , I inter changed changed the offset of red and blue bits. Now When I launch my application I can see blue window instead of yellow . Is this a right way to do it. I also see a PIXEL_FORMAT_BGRA_8888 in same format.cpp which satishfies my need. So I change the format in EGLDisplaySurface.cpp to GGL_PIXEL_FORMAT_BGRA_8888. But this don't seem to help me as I'm a seeing blank screen when I launch my above said application. Please let me know a proper way to do make use of BGRA_8888 format. Also where all should I change in Android If select this format. Please help regarding these issues Regards, Manjunath On Dec 9 2008, 8:00 am, Mathias Agopian <pixelflin...@google.com> wrote: > Hi, > > On Mon, Dec 8, 2008 at 6:19 PM, FlyCry <flycry...@gmail.com> wrote: > > > When I try to add a new pixel format for my board, I found a macro > > GGL_PIXEL_FORMAT_RGB_888 = 3, // 3x8-bitRGB > > I can use this format. Because the LCDC can use this 3x8-bit > > framebuffer to BGR666 output. > > And also I modified the EGLDisplaySurface.cpp to > > GGL_PIXEL_FORMAT_RGB_888. > > At that moment, I found red and blue are exchanged. Because of LCDC > > BGR666 output. > > So I modified load_store.cpp to exchange red and blue. > > Will the whole modified code break OpenGL? > > Yes. > > > Or if I want to use > > GGL_PIXEL_FORMAT_RGB_888, is there any way to make it to BGR without > > any change to load_store.cpp > > Yes. You need to create a new format, with a new unused constant. The > constant is a index in an array in pixelflinger/format.cpp -- you need > to add the format's description there (just swap the values for R and > B). Make sure EGLDisplaySurface.cpp returns your new format. > > And it should just work :-) > > Mathias > > ? > > > Thanks > > > On 12月8日, 下午3时50分, Mathias Agopian <pixelflin...@google.com> wrote: > >> Hi, > > >> I talked about this a littlebitin my 2nd answer to this thread. You > >> will have to create a new BGR pixel-format and use this one. Adding a > >> pixel format to the system is not too hard, but it requires adding a > >> constant into multiple files (and make sure they all match). > > >> For your information, a32-bits BGR format has been added to the > >> system after 1.0 was released (it is needed for the GPU to render into > >>32-bits surfaces). > > >> Have a look at pixelflinger's format.cpp, this is where the > >> pixelformats are defined, it will ripple from there (the corresponding > >> header file has a list of the other files that must be updated). > > >> Eventually, I should define all the useful pixelformat enums somewhere > >> so that we don't have collisions when people add new formats. > > >> In theory pixelfinger can handle pretty much any pixel configuration; > >> so we could add a mechanism to create formats at runtime, which would > >> also avoid the namespace problem. > > >> Mathias > > >> On Sun, Dec 7, 2008 at 8:39 PM, FlyCry <flycry...@gmail.com> wrote: > > >> > Hi, Mathias. Sorry to reply until now, cause somthing else I have to > >> > deal with in my job. > >> > I modified the assembly code of load_store.cpp. You mean that it would > >> > break GL_RGB? So if LCDC needs a BGR framebuffer, but android gives an > >> > RGB. What can I do to work it out? Could android give BGR display? > > >> > On 12月5日, 上午8时44分, David Given <d...@cowlark.com> wrote: > >> >> Mathias Agopian wrote: > > >> >> [...] > > >> >> > I don't understand what "looking at a GL_RGB pixel in a word" means. A > >> >> > word has32bits, GL_RGB has 24. > > >> >> Well, I thought it was pretty obvious --- you load your 24 bits, in > >> >> natural order, into the bottom end of a quad, exactly the same way that > >> >> you'd load a32bitvalue or a 16bitvalue or an 8bitvalue! > > >> >> The only thing that makes it the slightestbitcomplicated is that > >> >> GL_RGB is unaligned so you wouldn't be able to use a simple LDR > >> >> instruction, but that's just an implementation issue. > > >> >> -- > >> >> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────http://www.cowlark.com───── > >> >> │ > >> >> │ ⍎'⎕',∊N⍴⊂S←'←⎕←(3=T)⋎M⋏2=T←⊃+/(V⌽"⊂M),(V⊝"M),(V,⌽V)⌽"(V,V←1⎺1)⊝"⊂M)' > >> >> │ --- Conway's Game Of Life, in one line of APL > > >> >> signature.asc > >> >> < 1K查看下载- 隐藏被引用文字 - > > >> - 显示引用的文字 - -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
