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
-~----------~----~----~----~------~----~------~--~---
