Guest l2azor Posted November 1, 2011 Report Share Posted November 1, 2011 found this while random browsing..dont know if these optimisations are already used not..if not might be of use to developers... https://developer.qualcomm.com/file/6156 Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted November 1, 2011 Report Share Posted November 1, 2011 Interesting, but nothing in there that would help create a smooth ROM, in fact, a lot of it is more in the direction of gaming and graphics.... interesting linky though - ty :) Link to comment Share on other sites More sharing options...
Guest deksman2 Posted November 1, 2011 Report Share Posted November 1, 2011 (edited) A 'smooth' ROM can be gained via plenty of optimizations that are already done... but if you wanted to take this further up, then the UI needs to be completely rendered via the GPU... as does the browser, pinching, zooming, etc... However... Gingerbread seemingly supports partial gpu acceleration of it's UI... but not entirely. Ice Cream sandwich on the other hand (or Android 4.0) should have the entire UI hardware accelerated as far as I know... though google mentioned some kind of garbage about low end phones not having sufficient hardware capability for this which is why ICS won't have an official release for many devices... which in my opinion is a load of trash. Blade's hardware is enough to run the UI in full hardware acceleration... the gpu is certainly capable of producing well over 30FPS for UI drawing so there would be no lag. Edited November 1, 2011 by deksman2 Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted November 1, 2011 Report Share Posted November 1, 2011 (edited) A 'smooth' ROM can be gained via plenty of optimizations that are already done... but if you wanted to take this further up, then the UI needs to be completely rendered via the GPU... as does the browser, pinching, zooming, etc... However... Gingerbread seemingly supports partial gpu acceleration of it's UI... but not entirely. Ice Cream sandwich on the other hand (or Android 4.0) should have the entire UI hardware accelerated as far as I know... though google mentioned some kind of garbage about low end phones not having sufficient hardware capability for this which is why ICS won't have an official release for many devices... which in my opinion is a load of trash. Blade's hardware is enough to run the UI in full hardware acceleration... the gpu is certainly capable of producing well over 30FPS for UI drawing so there would be no lag. Uhmmm... I believe I mentioned this in another thread about optimizations. And also here, my opinion on this as well. Using Adreno is not the magic bullet for UI drawing... read the postings and you'll understand why :) Edited November 1, 2011 by t0mm13b Link to comment Share on other sites More sharing options...
Guest deksman2 Posted November 2, 2011 Report Share Posted November 2, 2011 (edited) Uhmmm... I believe I mentioned this in another thread about optimizations. And also here, my opinion on this as well. Using Adreno is not the magic bullet for UI drawing... read the postings and you'll understand why :) While I don't think that using the gpu is the magic bullet for UI drawing, it IS preferable. Why? Because you move away from taxing the CPU from doing things it doesn't have to, and the gpu would be more efficient for those tasks because that's what it was designed to do in the first place. It can also do this at a lower power level than the cpu (which is left to do other, more 'important' things). Also, the CPU (despite various optimization) can easily choke while viewing graphic heavy documents or websites (discernible lag)... whereas the gpu (if properly implemented) would not. The iPhone is a clear example of this (the 3G hardware is essentially identical to the Blade). Edited November 2, 2011 by deksman2 Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted November 2, 2011 Report Share Posted November 2, 2011 (edited) While I don't think that using the gpu is the magic bullet for UI drawing, it IS preferable. Why? Because you move away from taxing the CPU from doing things it doesn't have to, and the gpu would be more efficient for those tasks because that's what it was designed to do in the first place. It can also do this at a lower power level than the cpu (which is left to do other, more 'important' things). Also, the CPU (despite various optimization) can easily choke while viewing graphic heavy documents or websites (discernible lag)... whereas the gpu (if properly implemented) would not. The iPhone is a clear example of this (the 3G hardware is essentially identical to the Blade). Sure its preferrable, but, and this is the big BUT, that would reduce portability to another device if you write code that uses the GPU to do all the 2D drawing! That would effectively mean, having a lot of native code for ONE GPU chipset, what about another chipset used in another handset as well.... it goes on and on... and there you have a nice terminology - defragmentation.... Why do you think the majority of the android framework is written in Java? :rolleyes: For portability to ease the transition of Android to a new device... that's why... Sure JNI callbacks to the C native runtime to deal with that, but to be honest, JNI can be a chokepoint, shuffling from pure Java to native, and also, a lot of the java code is not really that optimized... I digress here and not getting into a big meaningless discussion with what the dalvikvm, runtime, apps running, kernel etc... Edited November 2, 2011 by t0mm13b Link to comment Share on other sites More sharing options...
Guest Hoonboof Posted November 4, 2011 Report Share Posted November 4, 2011 Sure its preferrable, but, and this is the big BUT, that would reduce portability to another device if you write code that uses the GPU to do all the 2D drawing! That would effectively mean, having a lot of native code for ONE GPU chipset, what about another chipset used in another handset as well.... it goes on and on... and there you have a nice terminology - defragmentation.... Why do you think the majority of the android framework is written in Java? :rolleyes: For portability to ease the transition of Android to a new device... that's why... Sure JNI callbacks to the C native runtime to deal with that, but to be honest, JNI can be a chokepoint, shuffling from pure Java to native, and also, a lot of the java code is not really that optimized... I digress here and not getting into a big meaningless discussion with what the dalvikvm, runtime, apps running, kernel etc... Its fragmentation not defragmentation, rewriting pixel/surface flinger in egl is doable, the reason it was never did was because Google felt that rewriting code to stop garbage collection happening so often would bring bigger gains (and on a lot of hardware this is very true, HTC hero a good example, software rasterisation of a lot of ops is faster). Why are you trying to talk down native code? If -anything- is going to get around garbage collection it's JNI. Good algorithms are better than optimisation, that's what jit is for! Link to comment Share on other sites More sharing options...
Guest deksman2 Posted November 5, 2011 Report Share Posted November 5, 2011 Ok... when it comes to fully HW accelerated UI... would it then be possible that the manufacturers of each phone are left to implement it? I mean, Android devs could simply allow for the option, but it would be up to the manufacturers to implement it for each device. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now