On Tue, Dec 2, 2008 at 11:45 PM, FlyCry <[EMAIL PROTECTED]> wrote: > > 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.
you mean red and blue, right? SurfaceFlinger should be using RGB (a byte of red followed by a byte of green, followed by a byte of blue). Unless there is a bug in pixelflinger, that's what it should do. I will check tomorrow if this is working properly (I don't think 24-bits mode have ever been used before). Mathias > 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: [email protected] >> [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: [email protected] >> > [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: [email protected] >> >> [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 -~----------~----~----~----~------~----~------~--~---
