For a production-quality device, you need hardware acceleration of at least surface compositing. This has become increasingly true as screen resolution has increased. The software rendering path for surface flinger is only there for bring-up and the emulator.
Further if you planning on running third party apps, you will need to have accelerated OpenGL available since many apps use that for their rendering. Going forward, you will want to have OpenGL 2.0 that is sufficiently robust to host HW accelerated drawing through Canvas, as introduced in Android 3.0. 2011/9/9 Xin Liu <navy.x...@gmail.com> > Dianne, > > it's not just broken. we does NOT have HW graphics at all. our CPU has a > plenty of hardware threads. we expect to write software graphics pipeline in > kernel and implement in-house opengl. s/w graphics will make use of > hardware threads to deliver decent performance. > > the graphics development are undergoing. we can only rely on libagl in > android now. Does a real vendor use libagl in products? On our CPU, it's > awful. i guess it's acceptable on ARM because i noticed that pixelflinger > and libagl had many ARM optimizations. Is it meaning for us to port JIT in > pixelflinger? I am not a graphics guy and expect a guide for further tuning > our android. > > thanks, > --lx > > 在 2011-9-9，下午1:55， Dianne Hackborn 写道： > > If the boot animation is that slow, your graphics driver is very broken. > > On Thu, Sep 8, 2011 at 10:26 PM, Liu Xin <navy.x...@gmail.com> wrote: > >> we ported android 2.3.1 to our architecture and board. the response time >> is terrible up now. >> >> according to my profile, i think it's because drawing windows are very >> slow. i have 2 clues which drawed my idea on graphics: >> >> i) bootanimation is slow; >> ideally, bootanimation is 12fps. however, we can only got 1 fps. it takes >> much more time in GL-functions. >> >> ii) >> i profiled Laucher and analyzed the data in traceview. it turns out that >> over 95% time Launcher consumed are for android.view.ViewRoot.handleMessage. >> >> >> on just group, some one complained that pixelflinger was significantly >> slower except ARM. it's because arm has a codeflinger which generates code >> on-the-fly. we are doing the similar optimization right now. >> >> thanks, >> --lx >> >> >> >> On Thu, Sep 1, 2011 at 2:51 AM, Pradeep <bhatt.prad...@gmail.com> wrote: >> >>> Hi, >>> >>> On my device the system regularly goes into a state where launch of >>> apps takes lot of time ( 5-10 secs ). This happens after using the >>> system for sometime and more often with apps with GLSurfaceView. >>> >>> My device config >>> >>> RAM - 384 MB >>> Resolution - 1024 * 600 >>> CPU - 1 Ghz Tegra dual core >>> >>> In this state I see a lot of processes being killed so I think >>> lowmemorykiller is running during this time. Also in adb shell cat / >>> proc/meminfo I see around 40-50 MB free but cache memory is on the >>> lower side. >>> >>> Any ideas ? >>> >>> Regards, >>> Pradeep >>> >>> -- >>> unsubscribe: android-porting+unsubscr...@googlegroups.com >>> website: http://groups.google.com/group/android-porting >>> >> >> >> -- >> unsubscribe: android-porting+unsubscr...@googlegroups.com >> website: http://groups.google.com/group/android-porting >> > > > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
