Please start your own thread instead of asking irrelevant questions on
existing ones.
the answer to your question is no, there isn't at the moment.
On Tue, Jan 27, 2009 at 7:03 AM, wing newton wrote:
>
> Greetings,
>
> Is there a .ISO for X86 Android or a bootable Android distribution
> availabl
Greetings,
Is there a .ISO for X86 Android or a bootable Android distribution available
that I can install it on a "pc" compatible device ?
thx.
--~--~-~--~~~---~--~~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/g
On Tue, Jan 27, 2009 at 1:40 AM, F H wrote:
>
> Hi Mathias,
>
> That is extremely helpful.
>
> Presumably, not having a kernel handle in shared memory is a security
> thing? Thus, if I needed to pass such a thing around I'd do it as a
> part of the Parcel.
right.
> Incidentally, if SurfaceFling
Hi Mathias,
That is extremely helpful.
Presumably, not having a kernel handle in shared memory is a security
thing? Thus, if I needed to pass such a thing around I'd do it as a
part of the Parcel.
Incidentally, if SurfaceFlinger doesn't use the surface-related
control block at all - then the re
On Mon, Jan 26, 2009 at 8:45 AM, F H wrote:
> Hi Mathias,
>
> - It seems to me that clients of SurfaceFlinger don't care about memory
> allocation and that accesses to surfaces are via GGLSurfaces, which just
> contain a pointer (not a base/offset combination). For a client, access to
> this poi
Hi Mathias,
- It seems to me that clients of SurfaceFlinger don't care about memory
allocation and that accesses to surfaces are via GGLSurfaces, which just
contain a pointer (not a base/offset combination). For a client, access to
this pointer is gated through the surface lock/unlock calls. So c
On Thu, Jan 22, 2009 at 3:04 PM, F H wrote:
>
> It goes back to my desire to use my own allocator for surface memory.
> I have a degree of enthusiasm to do this because many of our own
> underlying components (e.g. OpenGL ES, Video Codecs, Blit engines and
> so on) use our own abstraction rather
It goes back to my desire to use my own allocator for surface memory.
I have a degree of enthusiasm to do this because many of our own
underlying components (e.g. OpenGL ES, Video Codecs, Blit engines and
so on) use our own abstraction rather than a heap. So when a Surface
is to be allocated I ne
On Thu, Jan 22, 2009 at 2:46 PM, F H wrote:
>
> Thank you Mathias,
>
> Very helpful as usual.
>
> If I wanted to convey a bit more information between SurfaceFlinger
> and the client, would it be best to convey it via the control block or
> add it to the Parcel?
Can you elaborate? What informati
Thank you Mathias,
Very helpful as usual.
If I wanted to convey a bit more information between SurfaceFlinger
and the client, would it be best to convey it via the control block or
add it to the Parcel?
Fred.
On 1/22/09, Mathias Agopian wrote:
>
> Hi,
>
> On Tue, Jan 20, 2009 at 3:37 AM, F H
Hi,
On Tue, Jan 20, 2009 at 3:37 AM, F H wrote:
> Hi Mathias,
>
> Android typically creates two buffers per surface. Presumably this is so
> that one of them can be locked by an application for rendering while the
> other (complete buffer) is available to SurfaceFlinger for compositing?
correct
11 matches
Mail list logo
