Thanks for your helpful replies. Acctually, my lcdc support 24-bits packed framebuffer to 18-bits output to suit the 18bpp lcd. The framebuffer format is rrrrrr00gggggg00bbbbbb00, packed. I configed pixelflinger as RGB888. That could compatible to the 24- bits packed framebuffer. But I found the red and the green exchanged their place. Is android's default color space BGR but not RGB? The hardware can't swap red and green. Is there anything I can do to make android swap red and green. Thanks a lot.
On 12月2日, 下午6时39分, Phil HUXLEY <[EMAIL PROTECTED]> wrote: > Perhaps I wasn't being clear enough. Some LCD panels do have 18 bits per > pixel, but use some (2 or 3) of those bits for other things (can't remember > what), so the actual colour resolution is 16 bits or less. > > All I was suggesting was stay in a traditional 565 domain until the final > buffer swap to the screen (i.e. don't change any of the rendering side - > not even the configs), but do as efficient a conversion as possible on the > final swap - potentially easy to do if that final swap can be singled out. > > Mathias Agopian > <[EMAIL PROTECTED] > gle.com> To > Sent by: android-porting@googlegroups.com > [EMAIL PROTECTED] cc > ooglegroups.com > Subject > [android-porting] Re: Android > 02/12/2008 10:09 porting problem - LCD BPP > > Please respond to > [EMAIL PROTECTED] > ooglegroups.com > > On Tue, Dec 2, 2008 at 1:52 AM, Phil HUXLEY <[EMAIL PROTECTED]> wrote: > > I was thinking that the system would work in 16 bit more - 565 and just > > convert to 18 bit. i.e. the composition happens at 16 bit, not 32. It's > > What's the point of using a 18-bits framebuffer if most graphics are > done in 16-bits? I assumed, the goal would be to take advantage of the > extra 2 bits > > > definitely an overhead though. Is the screen update done via an > > eglSwapBuffers call on a single composited surface representing the > > screen? > > yes > > > It might not take very long to try it? and could be faster than the > > overheads bought about by dealing in 18 bit or 32 bit land when rendering > > (more bandwidth needed - particularly if pixels are touched multiple > > times). No obvious winner - it just might be quick to try. > > > Presumably the rendering routines in the software GL library would also > > have to be modified (unless the platform is using hardware). > > No, in this scenario, they would be rendering into a 565 buffer as > usual, which would be composited in 565, and eventually converted to > 666 during eglSwapBuffers(). GL doesn't need to be changed, just the > implementation of the EGLNativeWindowType. > > Unless the panel cannot be configured to 565 (that would be crazy), I > wouldn't go down that road, if it's not going to improve visual > quality. > > > > > > > > > > > Mathias Agopian > > <[EMAIL PROTECTED] > > gle.com> To > > Sent by: android-porting@googlegroups.com > > [EMAIL PROTECTED] cc > > ooglegroups.com > > Subject > > [android-porting] Re: Android > > 02/12/2008 09:43 porting problem - LCD BPP > > > Please respond to > > [EMAIL PROTECTED] > > ooglegroups.com > > > On Tue, Dec 2, 2008 at 1:25 AM, Phil HUXLEY <[EMAIL PROTECTED]> > wrote: > >> Alternatively, couldn't a blit be inserted somewhere such that a > > conversion > >> is done at the point of updating the display (and would this include a > >> regionlist of areas that have changed to optimise it?). Is there such an > >> 'update point'? > > > I think this would be slower generally. You'd end up doing all the > > composition in 32-bits, and then doing another copy/conversion by > > hand. I don't think it buys you anything. Also this would not match > > the EGL model very well, which SurfaceFlinger (very purposedly) relies > > on. > > > In my experience update regions don't buy you much because the case > > you care about is when you're "flinging" a list and that tends to > > update the whole screen; surfaceflinger uses them though. > > > I should have mentioned in the email before that pixelflinger has some > > logic to be able to replace the generated code by hand-written > > routines (see scanline.cpp). You'd want to do this for a few common > > operations like: RGBA32 -> RGB18 with and without blending. I think > > the code it'll generate won't be bad at all, but you'll be able to use > > pld() and/or process several pixels at a time. > > > One of the annoying part will be to chose a new constant for the new > > format. The namespace for those is limited and global to the platform > > (there are no way -yet- to create pixel formats dynamically at runtime > > -- which the codegen should be able to handle). We just need to be > > absolutely sure that whichever value we pick won't conflict with > > future version of the platform (I already added a few formats post > > 1.0). > > > Mathias > > >> Mathias Agopian > >> <[EMAIL PROTECTED] > >> gle.com> > To > >> Sent by: android-porting@googlegroups.com > >> [EMAIL PROTECTED] > cc > >> ooglegroups.com > > Subject > >> [android-porting] Re: Android > >> 02/12/2008 09:14 porting problem - LCD BPP > > >> Please respond to > >> [EMAIL PROTECTED] > >> ooglegroups.com > > >> On Mon, Dec 1, 2008 at 11:03 PM, FlyCry <[EMAIL PROTECTED]> wrote: > > >>> My lcdc support 2 format of 18bpp framebuffer. One is 18bpp packed. > >>> Another is a format of 3 byte: > >>> Red[5:0] 0 0 Green[5:0] 0 0 Blue[5:0] 0 0 > >>> could the second format be configed in android display? > > >> So there are no mode where it has the color components in the higher 6 > >> bits?! > > >> There is a way to configure pixelflinger to be able to render into > >> arbitrary bit-patterns, however, the format you're describing has > >> never been tested (obviously). It would also be a huge performance hit > >> because: > >> 1) we would have to make sure all windows are created in 32-bits (only > >> mode > 16 bits supported by the software render), which also implies > >> much higher memory usage and bus pressure > >> 2) the 32-bits surface will have to be converted at runtime and in > >> software to 18 bits. > > >> To make it work you'd have to add a new pixelformat describing your > >> framebuffer to pixelflinger, then you would have to make sure the code > >> that handles the framebuffer (EGLNativeDisplay.cpp) returns that. > >> You'd have to modify surfaceflinger to always create 32-bits surfaces. > >> Currently there is no abstraction for all these aspects, so it'll have > >> to be hacked in. > > >> On top of that, you'll have to replace all the 16-bits assets (because > >> you wouldnt' get any benefit otherwise). > > >> Performance will likely be bad do to the increased bus pressure, > >> memory usage and CPU pressure needed for conversion. > > >> I can't believe the framebuffer cannot be configured to 32-bits like > > this: > >> xxxxxxxxbbbbbb00gggggg00rrrrrr00 > >> this wouldn't cost anything more in h/w (just more address space, but > >> who cares?), and it would be a lot more efficient from a software > >> point of view. > > >> mathias > > >>> Thanks. > > >>> On 12月2日, 下午12时42分, Mathias Agopian <[EMAIL PROTECTED]> > >> wrote: > >>>> Hi, > > >>>> On Mon, Dec 1, 2008 at 8:22 PM, FlyCry <[EMAIL PROTECTED]> wrote: > > >>>> > My board has an lcd of 18 bpp, but android UI is 16 bpp. So the > >>>> > display is abnormal when andriod runs. Could android be configed to > > 18 > >>>> > bpp? And how to do it? > >>>> > Thanks for anyone attention to this topic. > > >>>> What's the format of your 18bpp framebuffer? (hopefully it's not 18bpp > >> packed!). > > >>>> Mathias > > >> ForwardSourceID:NT000040E6 > > > ForwardSourceID:NT000040F6 > > ForwardSourceID:NT0000410E- 隐藏被引用文字 - > > - 显示引用的文字 - --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
