Related
I hope this isn't perceived as spamming or fishing for votes. I think most of us would like to see a smoother Android GUI instead of that choppyness on our 1GHz phones. I and many people believe that Google can do something about this but are not prioritizing this as they should. I think we can change this by visiting and voting here, clicking on the star under the headline, if we want to see a change: http://code.google.com/p/android/issues/detail?id=6914
Who knows, if we start voting now, maybe they will implement this feature in the next Android version.
P.S. You need a Google account to be able to vote.
EDIT: Maybe this is why we haven't seen it yet?
From what I've heard, the fault lies mostly with HTC, encouraged by wholesale indifference by the carriers. Here's the story I was told:
* Qualcomm makes the core chipset used by most HTC phones, and most Android phones were built by HTC until VERY recently. Thus, the things that got the most attention during Android's first year and a half of commercial availability were things directly supported by HTC phones.
* The price charged by Qualcomm for its chipset varies, depending upon what features the handset manufacturer chooses to license from them. Put another way, every Qualcomm chip in a given family has the silicon resources to do everything... but manufacturers are only allowed to use the features they pay Qualcomm for the right to use.
* Because the carriers don't care, and the carriers are HTC's real customers, HTC didn't care about GPU support, either. It saved a few cents per phone, and washed its hands of GPU support to boot.
* Making matters worse, Qualcomm only makes its chipset documentation available under NDA (at least, the parts dealing with "premium" capabilities), and only made it available to licensees (of which there were very, very few). Ergo, the documentation has been VERY hard to come by, and less likely to be leaked by a public-minded HTC employee for the good of humanity.
Put another way, there probably isn't a thing Qualcomm can do to stop the folks at xda-developers.com from releasing guerrilla video drivers for HTC Android phones that take advantage of acceleration if they can figure out how it works, but you'll never see a phone come out of the box new with GPU acceleration unless HTC officially licenses the capability from Qualcomm. Nor will you see Google making it easy to do an end-run around the official release to graft it on, because then Qualcomm would sue THEM.
Click to expand...
Click to collapse
- This is from: http://androidforums.com/android-news-talk/29584-why-doesnt-androids-gui-use-gpu-acceleration.html
I starred it.
Definitely is bizarre that GPU integration isn't enabled in Android 2.1+
This hardware-can-do-qualcom-wont-allow-it is old...
It happens with a LOT of devices...
Sent from my HTC Desire using XDA App
I'm glad to see that we are climbing on the chart of issues.
I have come to notice that the issue of the choppy Android experience is not only a problem because of the lack of GPU acceleration. Android phones tend to respond to our gestures way too exactly. This results in uneven transitions, one half of the animation is fast and the other half is slower. This unevenness being a result of us not making, or following through, with perfectly even movements in terms of speed. I believe this is something Apple has addressed and they did it very nicely because even though you are moving your fingers unevenly and slowly, the UI transitions follows your finger in an even and smooth fashion but in a speed that matches your finger. This looks phenomenal. Same goes for faster input gestures, the Ios (iOS) responds in an even and smooth fashion but the transition is faster.
It was the same with my old HD1, the xda gpu-drivers helped alot. Looks like we'll have to take the matter into our own hands again.
Wasn't HTC mass-sued for this a while back?
Syc said:
It was the same with my old HD1, the xda gpu-drivers helped alot. Looks like we'll have to take the matter into our own hands again.
Wasn't HTC mass-sued for this a while back?
Click to expand...
Click to collapse
Nope. There was a whole load of talk of it over the TyTn II debacle, but the only thing to ever come of that was the rather excellent XDA GPU drivers.
I hate to admit this, but if Google, or whoever it is responsible, doesn't do something about this, I'll have to look elsewhere (Iphone). It might sound crazy but it's that important to me. I mean, it's so basic. Why add mega-ultra-fiction features and all other sh*t, when you don't know how to make a smooth transition. The basic element of the GUI.
Don't get me wrong, I don't like Apple, their policy or their attitude towards the rest. However, I'm being honest about this: they care. I haven't seen one Android phone capable of delivering smooth transitions although they are more powerful than the Iphones. On the one hand you have a team utilizing the entire potential of their sh**ty phones, and on the other hand you have a team doesn't give a rats a*s about the hardware in them.
I don't know if Google is to blame or the phone manufacturers. I just don't like the idea of owning a 1 GHz CPU and an awesome GPU (Samsung Galaxy S) and not being able to use it.
Sorry to bump an old thread.
Has there been any progress on this issue?
Using spare parts and setting all the window animations and transitions to very slow has made everything "smoother" to me for all purposes of discussion. during the slow but smooth transition, my phone has time to fully load the next screen or popup menu, therefore it all appears to happen seamlessly.
android is very smooth on my Hd2 ... Did you try a cyanogen mod build ?
Sorry, i was referring more towards the GPU being actively used by the UI front end.
Im using a Legend with Azure's cyanogen mod (froyo) things are pretty slick but I can tell when there are slowdowns, but the worst offender is definately the web browser.
The best example I can find is going to the html5 test website, I get a score of around 180 and the iphone about 140, but the legend browser (built in and Dolphin) really struggles to scroll that page, whereas on the Iphone its extremely smooth. Its these kind of inconsistencies which are annoying.
Another gripe is the whole portrait-landscape switch, its not gpu based in the least and its a rather half assed solution at the minute (visually). But I understand that no app could ever interfere with how this works as its so deep in the os? Such a shame.
I work in animation which is why im overly critical
I've just been reading the press release for the Samsun Vibrant, and T-Mobile says that the Vibrant has a six-axis sensor, which leads me to question, does this thing actually have a gyroscope? I've never heard anyone refer to a normal accelerometer as "six axis".
I believe that the six axis sensor is a gyroscope from a similar article that was posted for the VERIZON variant on phandroid tonight. Heres the link and if you read thru the article you will see where they kinda "confirm" that it is indeed a gyroscope.
phandroid.com/2010/06/27/verizon-wireless-announces-the-samsung-fascinate-another-galaxy-s-smartphone/
***EDIT***
Upon re-reading the article, IMO, its a toss up for me at the moment as to whether this is a true gyroscope, but im hopeful.
It does have a gyroscope.
The main difference between a gyro and an accelerometer is that a gyro can tell the difference between acceleration due to gravity and acceleration due to actual movement. It's a difference that sounds subtle until you try to implement something like an inverted pendulum (think: Segway or 2-wheeled balancing robot).
You can TRY to compensate by making use of background knowledge you have about the way the universe works (acceleration due to gravity is absolutely constant when the object is otherwise "motionless", whereas human-induced motion is never, ever going to be smooth or constant), but you're going to have zones of confusion where the algorithm just can't tell the difference between two different gestures.
A good analogy is the way multitouch works on the Nexus One and most other Android phones. By paying attention to the order in which the row-column virtual switches "close" and the way they change relative to each other, you can easily implement useful pinch-zoom. But try to implement virtual shiftkeys on a virtual keyboard with the keys rendered in their traditional positions, and your multitouch attempt will fail spectacularly when it can't reliably tell the difference between ctrl-w, ctrl-tab, alt-w, and alt-tab. Likewise, you can implement rough game control with accelerometers alone, but they'll work best in virtual tennis rackets, golf clubs, and bowling balls, where you have a hard swinging gesture through an arc followed by a sudden deceleration at the end that's easy to detect. Nintendo's choice of games for Wii Sports wasn't due to market research or coincidence... they picked the best use cases for using accelerometers alone as game controls.
Okay, so I got minecraft to work using Backtrack (HERE) in one of the other threads, but it runs poor(<1 FPS).
Basically, what I did was install the dummy video driver for xorg(xserver-xorg-video-dummy, iirc), and use THIS script to launch it. I then attached x11vnc to it.
The default TinyVNC server doesn't support OpenGL, you'll need to use xorg + x11vnc + the dummy
As far as getting minecraft to run, I got the appropriate liblwjgl build from HERE.
I got the appropriate jinput build from HERE
After you run MC for the first time, it'll download everything and crash. Replace the ~/.minecraft/bin/native/ files with the ones in these packages. The packages don't need to be installed, just extracted to get at those files.
You'll also need libmawt, provided by THIS package. That does need to be installed. Mine was broken on install, I didn't care to fix it, but it still worked. It just needs at that one file.
I got the best luck connecting to a network server with the MC process renice'd to -15 or so.
This is what should launch it:
Code:
./Xdummy :2 &
x11vnc -display :2 -noshm &
nice -n -15 java -jar minecraft.jar
Then connect to localhost:5900 for VNC.
As I said, it's unplayable right now. I was hoping someone could help come up with some ideas on getting it to play decently, as it's good for little more than getting on and chatting to people right now.
The only idea I had for boosting it was to find a tegra driver and try to get X to start with that without trying to attach to a VT(Will that dummy file do it?).
Also, the controls for VNC aren't suited for MC, obviously. I was using an external keyboard when I was playing with it.
I'll post a video of it running as soon as I can get a camera. My Iconia is my camera, heh.
Yeah, it runs poor on my HP Touchsmart tm2 with i3, so I doubt this would be any close. It's surprising though, considering the 8-bit graphics in the game itself.
Sent from my A500 using XDA Premium App
well thats 8 bit graphics on top of rendering millions and millions of cubes. from a game design stand point. its really impressive.
gh123man said:
well thats 8 bit graphics on top of rendering millions and millions of cubes. from a game design stand point. its really impressive.
Click to expand...
Click to collapse
I'm assuming that was sarcasm...
It really is impressive. Most 3d games contain static rendered floors and walls. Whereas Minecraft requires that each individual block be rendered as a stand-alone manipulative item. It really does require a lot of number crunching and resources.
Yea, MC's large memory usage isn't just inefficient code.
Haha, well you're right from the standpoint of the fact that it's millions of blocks rendered, but if it's going to be that intensive, why use the 8-bit blocks? I love the game, but honestly, it's a little frustrating that it only works on my quad-core desktop. I'm curious to see how much fog will have to be in place for the Xperia Play version out soon.
Sent from my A500 using XDA Premium App
cybermage1 said:
I'm assuming that was sarcasm...
Click to expand...
Click to collapse
*facepalm*
The amount of power needed to run something isn't just determined by flashy colours.
Maddmatt said:
*facepalm*
The amount of power needed to run something isn't just determined by flashy colours.
Click to expand...
Click to collapse
Right but seriously - a cube at most is three polygons (squares) rendered at any given time. You don't bother to render faces that you can't see due to occlusion. If you store the world in a matrix(s) optimized for calculating what's viewable then OpenGL with hardware acceleration handles all of that very well and very fast.
If you're telling me that the reason Minecraft performance sucks (and yes, I think we all agree it does) is because it's rendering so many cubes, and if that's correct.... then the developer is truly dumb. And rich, but still dumb.
I've done OpenGL and DirectX graphics programming for isometric views before and it's amazing the amount of data that can be rendered very fast on a 486 when done correctly.
The Tegra2 renders somewhere (couldn't find exact specs) near 35 million polygons per second. If Minecraft is generating 35 million polygons for every frame, that would explain the 1 fps and support my opinion.
But I digress from the original topic. It'd be nice if the developer would put out an optimized Android version - just think how many more of us (including me) would buy it yet AGAIN just to be able to play on our tablets and phones. lol.
Rendering isn't the only slow part, it has to calculate what to render, light, etc... for each block.
Each chunk (16x16x128) has 32768 blocks in it, at any one time you may have upwards 500 chunks loaded (checking right now, I have 441 after playing for maybe 20 minutes), that is 16,384,000 blocks. Granted, you're never rendering all of those at once, but just cycling through all of them and reading all of them is incredibly intensive, on both RAM and CPU.
In the MC code(Check MCP for tools to decompile and deobfuscate it), you'll see that he's only checking if another block is on the face, and using that to determine if that face should render or not. My assumption on this is that it's quicker to render a face than it is to check occlusion for it.
Also, beyond that, you'd have to consider other things, such as the overhead for things like the X server, VNC, and the obvious lack of hardware acceleration on the X server.
This is a must-read.
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
I gather a couple of interesting things from this: 1) the ICS OTA will be a drastic improvement over the ICS ROMs we have now, and 2) I thought it interesting how Google will actually improve UI smoothness in the Nexus S by turning OFF hardware acceleration in some areas.
This really clears up a lot of misconceptions and wrong information people around here seem to pass around regarding UI speed and hardware acceleration
Sent from my Galaxy Nexus using XDA App
Good find man, lot of useful info.
From Degobah
Utterly fantastic find, and a must-read for anyone concerned with Android UI performance. It's quite ironic that due to that 8-MB per-process memory hit, it's actually faster for the Nexus S to render parts of the UI in software. I wonder if the same driver limitations are present in iOS, since they use PowerVR GPUs as well.
For reference, I am including Dianne's complete post below.
Dianne Hackborn said:
How about some Android graphics true facts?
I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:
• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.
• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.
• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.
• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.
• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)
• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.
• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.
• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)
• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.
• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
Click to expand...
Click to collapse
Skimmed through it but it seems that its a compromise to free RAM but not really to speed up performance. Maybe faster app switching but not scrolling, animations, etc. Hopefully the Galaxy Nexus comes to Sprint.
Sent from my Nexus S using XDA App
Award Tour said:
Skimmed through it but it seems that its a compromise to free RAM but not really to speed up performance. Maybe faster app switching but not scrolling, animations, etc. Hopefully the Galaxy Nexus comes to Sprint.
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
1) Faster app-switching IS improved performance.
2) Maybe you skimmed past this part?
"A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps."
Click to expand...
Click to collapse
matt2053 said:
1) Faster app-switching IS improved performance.
2) Maybe you skimmed past this part?
Click to expand...
Click to collapse
Freeing RAM to allow more background processes and faster app switching would mean (app launching) performance that is no better than what we already have. With ICS and the anticipation of HW acceleration, we all wanted BETTER INTERACTIVE performance. From playing around with it on the AOSP build, I can clearly see its faster than 2.3 on that regard. I experience constant app relaunching, much more than 2.3 so maybe that's what Google is talking about. But Google scaling GPU acceleration back because of RAM limitations is kind of disappointing to me but understandable.
Sent from my Nexus S using XDA App
thnx for posting this again. I have read his post a while ago. And it was very informative. I am beginning to understand Android more. And I'm beginning to get more excited with the upcoming ICS update for our phone.
Award Tour said:
Freeing RAM to allow more background processes and faster app switching would mean performance that is no better than what we already have. With ICS and the anticipation of HW acceleration, we all wanted BETTER INTERACTIVE performance. From playing around with it on the AOSP build, I can clearly see its faster than 2.3 on that regard. I experience constant app relaunching, much more than 2.3 so maybe that's what Google is talking about. But Google scaling that back because of RAM limitations is kind of disappointing to me but understandable.
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
Yeah, I think the constant app re-launching is exactly what they are trying to fix by limiting the HW acceleration.
There are also several comments from other members of the Android team about how they are regularly blown away by how well the Nexus S Hummingbird processor handles SW rendering, and that it does so with such ease that you won't notice the difference, because it will be a steady 60 fps, and 60 fps is 60 fps to the user.
But the main thing that I think is important to take away from reading the post is that Google seems to know exactly wtf they're doing in this area, and they're doing a lot of work perfecting ICS performance on the Nexus S before they release it. So anyone who has felt disappointment regarding performance of ICS on the Nexus S so far can be assured that their apprehensions are indeed premature, and the Google team is keenly aware of the exact same performance issues that have been noted in this forum.
Plus they want it perfect on Nexus S because that seems to be the phone most Googlers personally own and use
Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
Click to expand...
Click to collapse
good enough explanation for me. So we can expect a better performing ICS for our nexus S. I am always pissed on how my nexus running on an alpha ICS rom can have a very very slow and painful app switching.
matt2053 said:
Yeah, I think the constant app re-launching is exactly what they are trying to fix by limiting the HW acceleration.
There are also several comments from other members of the Android team about how they are regularly blown away by how well the Nexus S Hummingbird processor handles SW rendering, and that it does so with such ease that you won't notice the difference, because it will be a steady 60 fps, and 60 fps is 60 fps to the user.
But the main thing that I think is important to take away from reading the post is that Google seems to know exactly wtf they're doing in this area, and they're doing a lot of work perfecting ICS performance on the Nexus S before they release it. So anyone who has felt disappointment regarding performance of ICS on the Nexus S so far can be assured that their apprehensions are indeed premature, and the Google team is keenly aware of the exact same performance issues that have been noted in this forum.
Plus they want it perfect on Nexus S because that seems to be the phone most Googlers personally own and use
Click to expand...
Click to collapse
I don't know about you but third party apps with hardware acceleration on is visibly more smooth than the same app on 2.3. Night and day difference. I wonder how much of it they're scaling back. Its too bad that you can't easily upgrade RAM on a phone.
Sent from my Nexus S using XDA App
Award Tour said:
I don't know about you but third party apps with hardware acceleration on is visibly more smooth than the same app on 2.3. Night and day difference. I wonder how much of it they're scaling back. Its too bad that you can't easily upgrade RAM on a phone.
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
I didn't get from her post that hardware rendering within app windows would be disabled. Just that certain parts of the UI will be drawn with software executed by the CPU.
Sent from my Galaxy Nexus using XDA App
Good read! Thanks for posting
Not bad
Thx
matt2053 said:
This is a must-read.
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
I gather a couple of interesting things from this: 1) the ICS OTA will be a drastic improvement over the ICS ROMs we have now, and 2) I thought it interesting how Google will actually improve UI smoothness in the Nexus S by turning OFF hardware acceleration in some areas.
This really clears up a lot of misconceptions and wrong information people around here seem to pass around regarding UI speed and hardware acceleration
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Thanks for the info
Sent from my Nexus S 4G using xda premium
My comments, since I do some graphics work professionally:
Either I'm reading this wrong or Android has an extremely stupid rendering design. I do professional embedded GL graphics (and some Qt) so I'm not up to date with the Android framework yet:
* Why isn't drawing a client-server model where all draw commands are funneled to a unified multi-threaded draw server? That way, each app doesn't need a 8MB chunk of driver memory (which is stupid in itself already especially on embedded, Windows Mobile, Qt on Windows Mobile, etc). Only full-screen apps should have direct rendering to the framebuffer. Android is already suffering from draw consistency, resource contention by allowing each app to direct render. C-S would separate touch event contention from drawing contention that each Android app suffers from and why iOS has smoother UI.
* Why isn't Android using a multi-process scene-graph (each app is a item, and then each item has multiple sub-graphs per app) so Android can not only retain what needs to be drawn per global animation updates, but can instantly and easily cull unnecessary updates per app. Putting each app into an overlay isn't the best way to go without this culling.
* Why isn't Android using "dirty-regions" as another way to cull necessary updates (I assume this is what tiles are)? It should be since its a standard technique that dates back to QuickDraw and QuickDraw II, besides MS's windows API.
* With the pixel-overdraw bandwidth issue, Android can easily first cull through the scene-graph, then the per-app dirty-regions (or stencil buffer*), and then use the hardware-accelerated *depthbuffer to eliminate more overdraw, and draw front-to-back. This is just simplified because there's more modern GL tricks for culling. So, Android shouldn't have to touch each displayed pixel more than once.
* Is Android using pixelshaders at all to accelerate standard widgets such as buttons, etc? There's no reason to have large simplified buttons that can't be replicated by instanced models with pixel-shaders in a scene-graph.
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.
.
lol in other words no iOS smoothness for us fail I hope ICS hooks up my nexus s tho
NuShrike said:
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.
Click to expand...
Click to collapse
Aye, I agree with you there!!!!!
NuShrike said:
My comments, since I do some graphics work professionally:
Either I'm reading this wrong or Android has an extremely stupid rendering design. I do professional embedded GL graphics (and some Qt) so I'm not up to date with the Android framework yet:
* Why isn't drawing a client-server model where all draw commands are funneled to a unified multi-threaded draw server? That way, each app doesn't need a 8MB chunk of driver memory (which is stupid in itself already especially on embedded, Windows Mobile, Qt on Windows Mobile, etc). Only full-screen apps should have direct rendering to the framebuffer. Android is already suffering from draw consistency, resource contention by allowing each app to direct render. C-S would separate touch event contention from drawing contention that each Android app suffers from and why iOS has smoother UI.
* Why isn't Android using a multi-process scene-graph (each app is a item, and then each item has multiple sub-graphs per app) so Android can not only retain what needs to be drawn per global animation updates, but can instantly and easily cull unnecessary updates per app. Putting each app into an overlay isn't the best way to go without this culling.
* Why isn't Android using "dirty-regions" as another way to cull necessary updates (I assume this is what tiles are)? It should be since its a standard technique that dates back to QuickDraw and QuickDraw II, besides MS's windows API.
* With the pixel-overdraw bandwidth issue, Android can easily first cull through the scene-graph, then the per-app dirty-regions (or stencil buffer*), and then use the hardware-accelerated *depthbuffer to eliminate more overdraw, and draw front-to-back. This is just simplified because there's more modern GL tricks for culling. So, Android shouldn't have to touch each displayed pixel more than once.
* Is Android using pixelshaders at all to accelerate standard widgets such as buttons, etc? There's no reason to have large simplified buttons that can't be replicated by instanced models with pixel-shaders in a scene-graph.
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.
Click to expand...
Click to collapse
In case anyone wonders, this was Romain Guy's reply to the questions above:
"We use dirty regions and overdraw would not be eliminated through the use of a depth buffer since pretty much everything drawn by apps requires blending. We user fragment shaders and instanced models already. Apps don't have access to the framebuffer, they draw inside what we call a "surface" which is basically an OpenGL texture used by a separate process (the window compositor.) Android 3.0 already moves towards a full scene graph approach by keeping a tree of display lists (one per View) inside each window."
Click to expand...
Click to collapse
barmanham said:
lol in other words no iOS smoothness for us fail I hope ICS hooks up my nexus s tho
Click to expand...
Click to collapse
I don't even consider iOS that smooth. Multitasking and app switching in that OS is a big pain. My IP4 and iPod touch 4th slows down a lot when multitasking. To a point that it freezes for seconds.
Sent from my Nexus S using XDA App
I posted with my girls pre 2 and the multitasking in that is perfect
Sent from Oxygen 2.3.2 powered Nexus S 4G
We're currently working on a handwriting app using a stylus for Android platforms. We can draw plenty fast enough to keep up with the user using a simple SurfaceView implementation. The problem is the ubiquitous Android touch lag that has been so well documented. I have not seen much of any improvement from ICS to JB. What we're currently seeing is a good 100+mS of lag when following a touch swipe on Android and actually being able to grab the coordinates from the OS. Our code basically runs the same now(as far as lag) whether it's on a quad core Galaxy Note or a dual core Marvell processor running at 800MHz. At this point I am frustrated with the state of the speed of the touch plumbing on Android. Now, I will be fair and state that I've tried some of the drawing apps on the iOS platform and at least in the drawing department, iOS isn't that much better than Android. The lag on iOS is nearly equivalent to Android. But note this is for drawing on the screen and following the touch events. All else; scrolling, swiping, iOS crushes Android as far as responsiveness. I recognize these devices are running a high level OS and we shouldn't expect real time performance but I am still frustrated to say the least. A good handwriting app needs a responsive touch system otherwise the human brain starts to disconnect their hand motion from what they see on the screen.
I've looked at the Seeder app but to be frank haven't used it since it requires a rooted device.
Can anyone chime in on the current state of the lag problem on Android? Are there are any solutions out there where we can get our apps to closely follow the touch coordinates without 100+mS of lag? I am willing to have to code my own plumbing to get the touch coordinates with less lag if that's what it takes.
http://www.macrumors.com/2013/09/21/iphone-5-touch-screen-twice-as-fast-as-android-touch-screen/
You've probably sorted this by now, but... specifically where do you observe 100ms lag ? From touching the screen to some point in your code ?
Even basic events like a button click don't fire for over 150ms after the user touches it. It's the same even when dealing with touch events directly.
i have some answer - sort of
microsoft is aiming for 1ms response time (other cmpys they wont say anything)
i dont think they have implemented in windows phone yet , but still i think response are pretty good compared to overloaded android
balance is must for any operationg system .
KurianOfBorg said:
Even basic events like a button click don't fire for over 150ms after the user touches it. It's the same even when dealing with touch events directly.
Click to expand...
Click to collapse
I'm a bit surprised by that, hadn't really noticed it on our app (which is a keyboard...) - how are you doing the measurement ? Would be interesting to give it a try.