Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
On Fri, Sep 17, 2010 at 7:54 PM, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. Use OpenGL ES. Seriously, you generally can't just accelerate one function and nothing else. What you will end up with is the worst of both worlds, as you take the hit of switching between hardware and software rendering all the time. If you just want to draw bitmaps to the screen, this can certainly be accomplished with Open GL ES, and you don't need to rely on the platform to provide you with essentially helper APIs to make it easier to do that particular special case. You can ask anyone here to write such a thing for you. Waiting for the platform to provide it is a really bad option because you don't know when it will be available (we don't really, either), and even once it does become available you can't really take advantage of it until it is available on the majority of the devices. There are so many things people can do without relying on the platform to give it to them in a nice little bundle. -- 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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
On 9/18/2010 2:23 PM, Dianne Hackborn wrote: On Fri, Sep 17, 2010 at 7:54 PM, Leigh McRae leigh.mc...@lonedwarfgames.com mailto:leigh.mc...@lonedwarfgames.com wrote: Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. Use OpenGL ES. As I stated, using OpenGL ES requires extra code. You to manage re-loading the assets such as textures and VBO. With the Android Activity life cycle this is even more of an issue than other platforms. This isn't trivial. It also exposes you to driver bugs/oddities. Seriously, you generally can't just accelerate one function and nothing else. What you will end up with is the worst of both worlds, as you take the hit of switching between hardware and software rendering all the time. You can actually. I don't think it's being suggested that you use the OpenGL driver to implement a basic bitblt. Its being suggested that the Android OS supports the ability for hardware to accelerate the bitblt. Maybe it already does, I don't know. If you just want to draw bitmaps to the screen, this can certainly be accomplished with Open GL ES, and you don't need to rely on the platform to provide you with essentially helper APIs to make it easier to do that particular special case. You can ask anyone here to write such a thing for you. Waiting for the platform to provide it is a really bad option because you don't know when it will be available (we don't really, either), and even once it does become available you can't really take advantage of it until it is available on the majority of the devices. There are so many things people can do without relying on the platform to give it to them in a nice little bundle. I don't think anyone is waiting. I believe it was just a request/suggestion. -- Dianne Hackborn Android framework engineer hack...@android.com mailto: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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
Bah, 2D in OpenGL really isn't that hard and there's not that much extra code. If someone were to just write a simple spriterenderer class that takes a set of bitmaps and lets you draw them wherever you want by index then improve it to handle an atlas of images for faster drawing and you've got 90% of most 2D game rendering code done right there, all in under a couple hundred or so lines. The lifecycle isn't that bad - all you ever have to do is reload vram- stored stuff like textures and VBOs, which I just have a method called vInit() that does that for any given renderer in the game, and when the gl context has changed, my main renderer just calls vInit() on all the subrenderers and all is back into the context and ready. I think that took me all of a few hours to get working correctly. On Sep 18, 1:55 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 9/18/2010 2:23 PM, Dianne Hackborn wrote: On Fri, Sep 17, 2010 at 7:54 PM, Leigh McRae leigh.mc...@lonedwarfgames.com mailto:leigh.mc...@lonedwarfgames.com wrote: Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. Use OpenGL ES. As I stated, using OpenGL ES requires extra code. You to manage re-loading the assets such as textures and VBO. With the Android Activity life cycle this is even more of an issue than other platforms. This isn't trivial. It also exposes you to driver bugs/oddities. Seriously, you generally can't just accelerate one function and nothing else. What you will end up with is the worst of both worlds, as you take the hit of switching between hardware and software rendering all the time. You can actually. I don't think it's being suggested that you use the OpenGL driver to implement a basic bitblt. Its being suggested that the Android OS supports the ability for hardware to accelerate the bitblt. Maybe it already does, I don't know. If you just want to draw bitmaps to the screen, this can certainly be accomplished with Open GL ES, and you don't need to rely on the platform to provide you with essentially helper APIs to make it easier to do that particular special case. You can ask anyone here to write such a thing for you. Waiting for the platform to provide it is a really bad option because you don't know when it will be available (we don't really, either), and even once it does become available you can't really take advantage of it until it is available on the majority of the devices. There are so many things people can do without relying on the platform to give it to them in a nice little bundle. I don't think anyone is waiting. I believe it was just a request/suggestion. -- Dianne Hackborn Android framework engineer hack...@android.com mailto: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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
Drawing a Bitmap using OpenGL is fairly trivial. (Granted they're power of 2.) (http://stackoverflow.com/questions/3553244/android-opengl-es-and-2d/3648054#3648054) There already exists several android game engines for this task such as: http://www.andengine.org/ Google already provides GLSurfaceView to handle lifecycle changes. Even using the native android widgets along your game is trivial using GLSurfaceView. Shouldn't take you more than a day or so to make your own engine and build your game around it without any bloat and learning something in the process. On Sat, Sep 18, 2010 at 11:55 AM, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 9/18/2010 2:23 PM, Dianne Hackborn wrote: On Fri, Sep 17, 2010 at 7:54 PM, Leigh McRae leigh.mc...@lonedwarfgames.com mailto:leigh.mc...@lonedwarfgames.com wrote: Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. Use OpenGL ES. As I stated, using OpenGL ES requires extra code. You to manage re-loading the assets such as textures and VBO. With the Android Activity life cycle this is even more of an issue than other platforms. This isn't trivial. It also exposes you to driver bugs/oddities. Seriously, you generally can't just accelerate one function and nothing else. What you will end up with is the worst of both worlds, as you take the hit of switching between hardware and software rendering all the time. You can actually. I don't think it's being suggested that you use the OpenGL driver to implement a basic bitblt. Its being suggested that the Android OS supports the ability for hardware to accelerate the bitblt. Maybe it already does, I don't know. If you just want to draw bitmaps to the screen, this can certainly be accomplished with Open GL ES, and you don't need to rely on the platform to provide you with essentially helper APIs to make it easier to do that particular special case. You can ask anyone here to write such a thing for you. Waiting for the platform to provide it is a really bad option because you don't know when it will be available (we don't really, either), and even once it does become available you can't really take advantage of it until it is available on the majority of the devices. There are so many things people can do without relying on the platform to give it to them in a nice little bundle. I don't think anyone is waiting. I believe it was just a request/suggestion. -- Dianne Hackborn Android framework engineer hack...@android.com mailto: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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- ~ Jeremiah:9:23-24 Android 2D MMORPG: http://developingthedream.blogspot.com/, http://diastrofunk.com, http://www.youtube.com/user/revoltingx -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
On 9/18/2010 5:24 PM, Robert Green wrote: Bah, 2D in OpenGL really isn't that hard and there's not that much extra code. If someone were to just write a simple spriterenderer class that takes a set of bitmaps and lets you draw them wherever you want by index then improve it to handle an atlas of images for faster drawing and you've got 90% of most 2D game rendering code done right there, all in under a couple hundred or so lines. No one was saying rendering 2D in OGL was hard and I think you're vastly over simplifying things. Actually I just Googled this from your own journal: Android is none too easy to develop OpenGL apps for. http://www.rbgrn.net/content/215-light-racer-3d-development-journal As soon as you have OGL in the picture you have to deal with alot of stuff like pow2 textures, texture formats, state changes, viewport, different drivers etc. My current game Tank Recon 3D is suffering a crash on the HTC Hero that is in the OGL driver. There is also a thread going on talking about a really hard to find OGL crash. Why would you want to subject yourself to this if you're game is all about pushing 2D sprites? I'm not trying to be negitive but the reality is if I don't have to use a 3D api for 2D stuff I won't. Freddy Falling, Freddy Jump and Wrath all use the 2D API and were MUCH MUCH easier to write and handle the Activity lifecycle. The lifecycle isn't that bad - all you ever have to do is reload vram- stored stuff like textures and VBOs, which I just have a method called vInit() that does that for any given renderer in the game, and when the gl context has changed, my main renderer just calls vInit() on all the subrenderers and all is back into the context and ready. I think that took me all of a few hours to get working correctly. I don't agree with you there at all. For one thing an OGL context gets kicked out far more often than a full Activity does. Now your game also has to manage reloading all the resources which it might not have been written to track. I think the original point was that it would be nice if you could do a simple bitblt that was hardware accelerated using the 2D API. On Sep 18, 1:55 pm, Leigh McRaeleigh.mc...@lonedwarfgames.com wrote: On 9/18/2010 2:23 PM, Dianne Hackborn wrote: On Fri, Sep 17, 2010 at 7:54 PM, Leigh McRae leigh.mc...@lonedwarfgames.com mailto:leigh.mc...@lonedwarfgames.com wrote: Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. Use OpenGL ES. As I stated, using OpenGL ES requires extra code. You to manage re-loading the assets such as textures and VBO. With the Android Activity life cycle this is even more of an issue than other platforms. This isn't trivial. It also exposes you to driver bugs/oddities. Seriously, you generally can't just accelerate one function and nothing else. What you will end up with is the worst of both worlds, as you take the hit of switching between hardware and software rendering all the time. You can actually. I don't think it's being suggested that you use the OpenGL driver to implement a basic bitblt. Its being suggested that the Android OS supports the ability for hardware to accelerate the bitblt. Maybe it already does, I don't know. If you just want to draw bitmaps to the screen, this can certainly be accomplished with Open GL ES, and you don't need to rely on the platform to provide you with essentially helper APIs to make it easier to do that particular special case. You can ask anyone here to write such a thing for you. Waiting for the platform to provide it is a really bad option because you don't know when it will be available (we don't really, either), and even once it does become available you can't really take advantage of it until it is available on the majority of the devices. There are so many things people can do without relying on the platform to give it to them in a nice little bundle. I don't think anyone is waiting. I believe it was just a request/suggestion. -- Dianne Hackborn Android framework engineer hack...@android.commailto: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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh
Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
Drawing a Bitmap using OpenGL is fairly trivial. (Granted they're power of 2.) (http://stackoverflow.com/questions/3553244/android-opengl-es-and-2d/3648054#3648054) That whole example is trivial and is missing alot of boiler plate. There already exists several android game engines for this task such as: http://www.andengine.org/ Google already provides GLSurfaceView to handle lifecycle changes. Even using the native android widgets along your game is trivial using GLSurfaceView. GLSurfaceView, the last time I check, handles nothing as far a lifecylce is concerned. It gives you callbacks when you loose your surface. Big deal, so does SurfaceHolder. Shouldn't take you more than a day or so to make your own engine and build your game around it without any bloat and learning something in the process. I think you're missing the point. I also think you are clearly under estimating the time invloved. I have done both BTW. On Sat, Sep 18, 2010 at 11:55 AM, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 9/18/2010 2:23 PM, Dianne Hackborn wrote: On Fri, Sep 17, 2010 at 7:54 PM, Leigh McRae leigh.mc...@lonedwarfgames.commailto:leigh.mc...@lonedwarfgames.com wrote: Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. Use OpenGL ES. As I stated, using OpenGL ES requires extra code. You to manage re-loading the assets such as textures and VBO. With the Android Activity life cycle this is even more of an issue than other platforms. This isn't trivial. It also exposes you to driver bugs/oddities. Seriously, you generally can't just accelerate one function and nothing else. What you will end up with is the worst of both worlds, as you take the hit of switching between hardware and software rendering all the time. You can actually. I don't think it's being suggested that you use the OpenGL driver to implement a basic bitblt. Its being suggested that the Android OS supports the ability for hardware to accelerate the bitblt. Maybe it already does, I don't know. If you just want to draw bitmaps to the screen, this can certainly be accomplished with Open GL ES, and you don't need to rely on the platform to provide you with essentially helper APIs to make it easier to do that particular special case. You can ask anyone here to write such a thing for you. Waiting for the platform to provide it is a really bad option because you don't know when it will be available (we don't really, either), and even once it does become available you can't really take advantage of it until it is available on the majority of the devices. There are so many things people can do without relying on the platform to give it to them in a nice little bundle. I don't think anyone is waiting. I believe it was just a request/suggestion. -- Dianne Hackborn Android framework engineer hack...@android.commailto: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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
That whole example is trivial and is missing alot of boiler plate. Because it is a trivial task There already exists several android game engines for this task such as: http://www.andengine.org/ Google already provides GLSurfaceView to handle lifecycle changes. Even using the native android widgets along your game is trivial using GLSurfaceView. GLSurfaceView, the last time I check, handles nothing as far a lifecylce is concerned. It gives you callbacks when you loose your surface. Big deal, so does SurfaceHolder. Didn't you look at andengine? GLSurfaceView is just like a view, you don't ever handle lifecycle changes from a view point of view so it removes that burden from the pictures. You handle this from your activity. Changing your view port is ridiculously easy if you detect the view size has changed. Shouldn't take you more than a day or so to make your own engine and build your game around it without any bloat and learning something in the process. I think you're missing the point. I also think you are clearly under estimating the time invloved. I have done both BTW. I've done this, I wrote a complete game prototype in a week. It was really easy. You really have to be an incompetent programmer if you don't write code that handles things such as different screen sizes automatically. On Sat, Sep 18, 2010 at 11:55 AM, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: On 9/18/2010 2:23 PM, Dianne Hackborn wrote: On Fri, Sep 17, 2010 at 7:54 PM, Leigh McRae leigh.mc...@lonedwarfgames.commailto:leigh.mc...@lonedwarfgames.com wrote: Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. Use OpenGL ES. As I stated, using OpenGL ES requires extra code. You to manage re-loading the assets such as textures and VBO. With the Android Activity life cycle this is even more of an issue than other platforms. This isn't trivial. It also exposes you to driver bugs/oddities. Seriously, you generally can't just accelerate one function and nothing else. What you will end up with is the worst of both worlds, as you take the hit of switching between hardware and software rendering all the time. You can actually. I don't think it's being suggested that you use the OpenGL driver to implement a basic bitblt. Its being suggested that the Android OS supports the ability for hardware to accelerate the bitblt. Maybe it already does, I don't know. If you just want to draw bitmaps to the screen, this can certainly be accomplished with Open GL ES, and you don't need to rely on the platform to provide you with essentially helper APIs to make it easier to do that particular special case. You can ask anyone here to write such a thing for you. Waiting for the platform to provide it is a really bad option because you don't know when it will be available (we don't really, either), and even once it does become available you can't really take advantage of it until it is available on the majority of the devices. There are so many things people can do without relying on the platform to give it to them in a nice little bundle. I don't think anyone is waiting. I believe it was just a request/suggestion. -- Dianne Hackborn Android framework engineer hack...@android.commailto: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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at
Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
That whole example is trivial and is missing alot of boiler plate. Because it is a trivial task Good news! Post the code when you're done... There already exists several android game engines for this task such as: http://www.andengine.org/ Google already provides GLSurfaceView to handle lifecycle changes. Even using the native android widgets along your game is trivial using GLSurfaceView. GLSurfaceView, the last time I check, handles nothing as far a lifecylce is concerned. It gives you callbacks when you loose your surface. Big deal, so does SurfaceHolder. Didn't you look at andengine? I am sure it's great but I have my own code. Actually why do you need a 2D OGL engine if it's such a trivial task? My assertion stands that GLSurfaceView does nothing to handle Activity Lifecycle. On BlackBerry when you loose focus and have been put into the background, the OS handles it. GLSurfaceView just lets you know you're context is dead and it's up to you to rebuild it all. So what is it handling that a regular SurfaceHolder isn't? GLSurfaceView is just like a view, you don't ever handle lifecycle changes from a view point of view so it removes that burden from the pictures. You handle this from your activity. Changing your view port is ridiculously easy if you detect the view size has changed. Shouldn't take you more than a day or so to make your own engine and build your game around it without any bloat and learning something in the process. I think you're missing the point. I also think you are clearly under estimating the time invloved. I have done both BTW. I've done this, I wrote a complete game prototype in a week. It was really easy. You really have to be an incompetent programmer if you don't write code that handles things such as different screen sizes automatically. No need to throw stones :) I have worked on many games thank you, 8 of which shipped. Screen size isn't the issue. People, this is just a request. It would only make the platform better. On Sat, Sep 18, 2010 at 11:55 AM, Leigh McRae leigh.mc...@lonedwarfgames.comwrote: On 9/18/2010 2:23 PM, Dianne Hackborn wrote: On Fri, Sep 17, 2010 at 7:54 PM, Leigh McRae leigh.mc...@lonedwarfgames.commailto:leigh.mc...@lonedwarfgames.com wrote: Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. Use OpenGL ES. As I stated, using OpenGL ES requires extra code. You to manage re-loading the assets such as textures and VBO. With the Android Activity life cycle this is even more of an issue than other platforms. This isn't trivial. It also exposes you to driver bugs/oddities. Seriously, you generally can't just accelerate one function and nothing else. What you will end up with is the worst of both worlds, as you take the hit of switching between hardware and software rendering all the time. You can actually. I don't think it's being suggested that you use the OpenGL driver to implement a basic bitblt. Its being suggested that the Android OS supports the ability for hardware to accelerate the bitblt. Maybe it already does, I don't know. If you just want to draw bitmaps to the screen, this can certainly be accomplished with Open GL ES, and you don't need to rely on the platform to provide you with essentially helper APIs to make it easier to do that particular special case. You can ask anyone here to write such a thing for you. Waiting for the platform to provide it is a really bad option because you don't know when it will be available (we don't really, either), and even once it does become available you can't really take advantage of it until it is available on the majority of the devices. There are so many things people can do without relying on the platform to give it to them in a nice little bundle. I don't think anyone is waiting. I believe it was just a request/suggestion. -- Dianne Hackborn Android framework engineer hack...@android.commailto: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. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group,
Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate. On 9/16/2010 2:35 PM, Romain Guy wrote: Again, it really depends on what the application does exactly. If you are always drawing the same translucent bitmap on screen, the GPU will be better. If you are drawing complex shaded and antialiased paths or you draw a bitmap that changes often, things can get pretty bad. Some features of the Canvas API require other kinds of expensive operations (for instance, implementing saveLayer/saveLayerAlpha requires the use of FBOs or glCopyTexImage2D and neither solution is ideal.) On Thu, Sep 16, 2010 at 11:20 AM, markusn82markus...@gmail.com wrote: Thanks for the response. I know that mobile GPUs are tile-based and aren't great in terms of raw pixel processing power, but the pixel throughput would definitely be miles ahead of a general purpose CPU. I'm sure you guys have already considered this angle, but instead of using OpenGL why couldn't you create a custom 2D graphics library for vendors to implement at the lower level? As a side note, I just found a lengthy discussion of this issue here: http://code.google.com/p/android/issues/detail?id=6914 On Sep 16, 1:50 pm, Romain Guyromain...@android.com wrote: Hi, This is something we have investigated several times in the past. The biggest issue with hardware acceleration of the 2D drawing API is coverage. Many features offered by the existing 2D APIs are difficult or extremely expensive to implement using OpenGL. There are also issues with various OpenGL implementations. As game developers know very well, different GPUs and OpenGL drivers sometimes behave a little differently or suffer from different bugs. By using a software rendering API we can guarantee rendering fidelity across all devices. There is also the problem that mobile GPUs are not all well suited for the kind of operations required by a 2D drawing API as currently used by the Android UI toolkit (fill rate or shaders complexity can be a problem for instance.) Hardware acceleration of the drawing APIs is something we would love to have but it is by no means a magic bullet that's going to solve all issues. For what it's worth, window composition is already hardware accelerated and has been so since Android 1.0. On Thu, Sep 16, 2010 at 10:36 AM, markusn82markus...@gmail.com wrote: I've been developing Android application for quite awhile now. Please correct me if I'm wrong, but as far as I know the UI toolkit and 2D graphics API aren't hardware accelerated (the official documentation states that Canvas is not accelerated). I've found that most non- trivial animation or blending operations are painfully slow even on mid-level devices like a Droid, even after taking much time to optimize my code. I'd like to know what the rationale is for not providing hardware support for these frameworks? Wouldn't it be possible to at least make it optional for vendors to implement support? Does anyone have any additional information about this issue? Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
Thanks for the response. I know that mobile GPUs are tile-based and aren't great in terms of raw pixel processing power, but the pixel throughput would definitely be miles ahead of a general purpose CPU. I'm sure you guys have already considered this angle, but instead of using OpenGL why couldn't you create a custom 2D graphics library for vendors to implement at the lower level? As a side note, I just found a lengthy discussion of this issue here: http://code.google.com/p/android/issues/detail?id=6914 On Sep 16, 1:50 pm, Romain Guy romain...@android.com wrote: Hi, This is something we have investigated several times in the past. The biggest issue with hardware acceleration of the 2D drawing API is coverage. Many features offered by the existing 2D APIs are difficult or extremely expensive to implement using OpenGL. There are also issues with various OpenGL implementations. As game developers know very well, different GPUs and OpenGL drivers sometimes behave a little differently or suffer from different bugs. By using a software rendering API we can guarantee rendering fidelity across all devices. There is also the problem that mobile GPUs are not all well suited for the kind of operations required by a 2D drawing API as currently used by the Android UI toolkit (fill rate or shaders complexity can be a problem for instance.) Hardware acceleration of the drawing APIs is something we would love to have but it is by no means a magic bullet that's going to solve all issues. For what it's worth, window composition is already hardware accelerated and has been so since Android 1.0. On Thu, Sep 16, 2010 at 10:36 AM, markusn82 markus...@gmail.com wrote: I've been developing Android application for quite awhile now. Please correct me if I'm wrong, but as far as I know the UI toolkit and 2D graphics API aren't hardware accelerated (the official documentation states that Canvas is not accelerated). I've found that most non- trivial animation or blending operations are painfully slow even on mid-level devices like a Droid, even after taking much time to optimize my code. I'd like to know what the rationale is for not providing hardware support for these frameworks? Wouldn't it be possible to at least make it optional for vendors to implement support? Does anyone have any additional information about this issue? Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
I don't think a lot of developers would need the entire 2D drawing API to be hardware accelerated. If we could just render stuff to bitmaps/ layers that we can freely move around and send those to the GPU compositor that would be great for animation, scrolling, etc. On Sep 16, 7:50 pm, Romain Guy romain...@android.com wrote: Hi, This is something we have investigated several times in the past. The biggest issue with hardware acceleration of the 2D drawing API is coverage. Many features offered by the existing 2D APIs are difficult or extremely expensive to implement using OpenGL. There are also issues with various OpenGL implementations. As game developers know very well, different GPUs and OpenGL drivers sometimes behave a little differently or suffer from different bugs. By using a software rendering API we can guarantee rendering fidelity across all devices. There is also the problem that mobile GPUs are not all well suited for the kind of operations required by a 2D drawing API as currently used by the Android UI toolkit (fill rate or shaders complexity can be a problem for instance.) Hardware acceleration of the drawing APIs is something we would love to have but it is by no means a magic bullet that's going to solve all issues. For what it's worth, window composition is already hardware accelerated and has been so since Android 1.0. On Thu, Sep 16, 2010 at 10:36 AM, markusn82 markus...@gmail.com wrote: I've been developing Android application for quite awhile now. Please correct me if I'm wrong, but as far as I know the UI toolkit and 2D graphics API aren't hardware accelerated (the official documentation states that Canvas is not accelerated). I've found that most non- trivial animation or blending operations are painfully slow even on mid-level devices like a Droid, even after taking much time to optimize my code. I'd like to know what the rationale is for not providing hardware support for these frameworks? Wouldn't it be possible to at least make it optional for vendors to implement support? Does anyone have any additional information about this issue? Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Why aren't the 2D graphics API UI toolkit hardware accelerated?
Again, it really depends on what the application does exactly. If you are always drawing the same translucent bitmap on screen, the GPU will be better. If you are drawing complex shaded and antialiased paths or you draw a bitmap that changes often, things can get pretty bad. Some features of the Canvas API require other kinds of expensive operations (for instance, implementing saveLayer/saveLayerAlpha requires the use of FBOs or glCopyTexImage2D and neither solution is ideal.) On Thu, Sep 16, 2010 at 11:20 AM, markusn82 markus...@gmail.com wrote: Thanks for the response. I know that mobile GPUs are tile-based and aren't great in terms of raw pixel processing power, but the pixel throughput would definitely be miles ahead of a general purpose CPU. I'm sure you guys have already considered this angle, but instead of using OpenGL why couldn't you create a custom 2D graphics library for vendors to implement at the lower level? As a side note, I just found a lengthy discussion of this issue here: http://code.google.com/p/android/issues/detail?id=6914 On Sep 16, 1:50 pm, Romain Guy romain...@android.com wrote: Hi, This is something we have investigated several times in the past. The biggest issue with hardware acceleration of the 2D drawing API is coverage. Many features offered by the existing 2D APIs are difficult or extremely expensive to implement using OpenGL. There are also issues with various OpenGL implementations. As game developers know very well, different GPUs and OpenGL drivers sometimes behave a little differently or suffer from different bugs. By using a software rendering API we can guarantee rendering fidelity across all devices. There is also the problem that mobile GPUs are not all well suited for the kind of operations required by a 2D drawing API as currently used by the Android UI toolkit (fill rate or shaders complexity can be a problem for instance.) Hardware acceleration of the drawing APIs is something we would love to have but it is by no means a magic bullet that's going to solve all issues. For what it's worth, window composition is already hardware accelerated and has been so since Android 1.0. On Thu, Sep 16, 2010 at 10:36 AM, markusn82 markus...@gmail.com wrote: I've been developing Android application for quite awhile now. Please correct me if I'm wrong, but as far as I know the UI toolkit and 2D graphics API aren't hardware accelerated (the official documentation states that Canvas is not accelerated). I've found that most non- trivial animation or blending operations are painfully slow even on mid-level devices like a Droid, even after taking much time to optimize my code. I'd like to know what the rationale is for not providing hardware support for these frameworks? Wouldn't it be possible to at least make it optional for vendors to implement support? Does anyone have any additional information about this issue? Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
