Thanks Mathias,
I'm still unclear as to why you think it won't work if the following is true:
- SurfaceFlinger is the only thing that allocates surface memory,
which is exposed to the outside world as a base heap-pointer plus
offset.
- Clients don't do any memory management, but always used their
SurfaceFlinger is the surface compositor and PixelFlinger is the
blitter.
On Jan 17, 5:08 am, "Chen Yang" wrote:
> Hi Mathias:
> Just interested to know, what's the relationship between surfaceflinger
> and pixelflinger?
> Meanwhile, is there some document on sufraceflinger and pixelflin
Hi Mathias:
Just interested to know, what's the relationship between surfaceflinger
and pixelflinger?
Meanwhile, is there some document on sufraceflinger and pixelflinger?
Thanks.
--
Chen
On Sat, Jan 17, 2009 at 5:58 AM, Mathias Agopian wrote:
>
> On Fri, Jan 16, 2009 at 8:18 AM, F H wr
On Fri, Jan 16, 2009 at 8:18 AM, F H wrote:
> Thanks Mathias, that helps *a lot*.
>
> My brain hurts from looking at the memory stuff!
>
> I can now see that each client maps in the 8Mb shared memory region once.
>
> What I don't understand at the moment is where the pointer to the surface
> data
Thanks Mathias, that helps *a lot*.
My brain hurts from looking at the memory stuff!
I can now see that each client maps in the 8Mb shared memory region once.
What I don't understand at the moment is where the pointer to the surface
data is passed back to the client - can you say at what point t
Hi,
On Thu, Jan 15, 2009 at 9:53 AM, F H wrote:
> I have a few questions regarding integration of an accelerated capability
> into Android.
Before we go further, I would like to point out that there are no
OpenGL ES driver model in Android 1.0. We're trying very hard to
finalize it for the cupc
