[Suggestion] Low battery mode for Non Game Apps

Unity3d has the best presentation layer for cross platform development out there. Compared to having to write everything multiple times for each platforms, or the difficulties of Xamarin, or even phone gap.. Unity3d just blows the competition away.

When non game customers come to me with an Idea, 90% of the time Unity3d would do the trick... If it wasn't for the battery drain.

Here is a picture comparing battery drain between a Xamarin Forms application and a Unity3d application.


Trepn profile is the tool. % use is normalized. Tests were for a period of 30 seconds each.


As you can see the Xamarin forms application uses very little battery compared to my empty Unity3d project.

To any Unity3d staff out there, is there a way we can make Unity3d more energy efficient ? If we could slow the update rate, or disable advanced shaders, or whatever ? Maybe a new menu where we can enable / disable features with an energy / space estimation.

I understand that Unity3d is at its core a game engine, but, vertical enterprises business have lots of money and I am certain that an update with support for an energy efficient mode would really expand Unity's utility value.

Lastly, if this is possible but you need someone who has an understanding of LOB's to bounce ideas off of or prototype, mail me.

Reddit Link

Relevant :

 

Ultimately this is the issue with having a core tied so closely to the game loop. You could drop the target frame rate down, at the risk of making your ap unresponsive.

Most of the current unity users would be opposed to moving away from the core game loop.

 

@BoredMormon. I think your right. Im going to run some tests.

 

There are things you can do to reduce the hit, and certainly we would all welcome continued improvement on unity's side. But it is too niche and off-product to expect much movement from unity in that direction.

Tools for building apps are plentiful and feature rich, unity would have to change a lot to even come close, even then it would be tough to convince devs to change. If there was a clear gap or the market was under served, it might make sense but that's just not the case. Though it is quite useful for non game apps that are 3d centric.

 

What do you mean by niche ? Most apps are non-game and would benifit from efficient battery use.

 

Niche in terms of devs that would use unity for non game/3d app development. Of course better battery usage would be fantastic, and I assume that unity is not ignoring it. But there is a certain amount overhead in a 3d engine and especially a game engine not needed for most non game apps. Decoupling that would be non-trivial, and not benefit their core use/audience.

 

Sure, but most such apps are already very well serviced by frameworks targeting that use case. The "niche" is stuff that is a hybrid of the two, and even that is likely to be well serviced in the not-too-distant future thanks to WebGL.

 

Not only non-game apps would benefit from this, games such as choose-your-path books (I think a few of them are made in Unity), turn-based tabletop inspired games and card games etc might/should also benefit (quite largely some of them) if you could slow down the core game loop/or something else to keep power usage down while keeping the game responsive when used.
Hmm, would something like this help:

Code (CSharp):

1. public class PowerSavingTest : MonoBehaviour {
2.  
3.     private bool _savingPower = false;
4.  
5.     private float _lastNonSaveTime = 0f;
6.    
7.     public void SavePowerMode(bool save) {
8.  
9.         if (savingPower==save) return;
10.  
11.         if (save)
12.             Application.targetFrameRate = 5;
13.         else
14.         {
15.             Application.targetFrameRate = -1;
16.         }
17.         savingPower = save;
18.     }
19.  
20.     void FixedUpdate() {
21.         if (some kind of input)
22.         {
23.             _lastNonSaveTime = Time.time;
24.             SavePowerMode(false);
25.         } else
26.         {
27.             if (Time.time + 0.1f > _lastNonSaveTime)
28.                 SavePowerMode(true);
29.         }
30.     }
31. }
32.  

 

Right now developers have 4 options.

1) Native development in objective-C and java. This method has 0% code reuse. Simply put you need to write a new app for each platform. In the future no one should be doing this.


2) Webview technologies like cordova and phone gap. Developers make their applications in html, css, and js. These technologies are growing because they allow for 100% code reuse between iOS and Android. Their pitfall is that they use js and not everyone loves this. Moreover the web view has a performance hit.

3) Xamarin Forms. Developers use c# and xaml to make their applications. There is 95% code reuse across both platforms. The biggest pitfall is that their ui technology sucks. Specifically because it renders 'native' controls each platform functions and looks different.

4) Unity3d. With its world class UI, near 100% code reuse, and world class UI this is the best option for all mobile development. If this battery issue can be resolved ,any developer worth their salt should seriously look into unity for all mobile applications. Seriously, the second biggest hurdle is a perception problem. Marketing.

I currently support 2 non game applications. 1) a video conferencing app. 2) a customer and order management solution. I would love to move these into Unity.

 

At 1 FPS Im seeing CPU usage at about 8%. That is almost a 50% reduction.

I should add that Facebook has CPU use is about 5%. Keep in mind that Facebook has allot more going on that my simple button and slider... but, I think we might be in the ballpark.

I will run some more tests and write a blog post this week.

 

Even if they could improve it a bit you will still face Apple and iOS users that dislike apps that do not behave like normal apps. You might get away with simple looking apps but if there are a lot of views and UI behavior created in a custom way you probably will get rejected.

Xamarin does it like its supposed to be, native looking controls which of course behave and look different depending of the platform and version but in a way the platform users are used of. You also did not list all all options as there are also other solutions for multiplatform apps that do native controls.

If you don't use native looking UI you are promoting the hated wild west apps where every developer has it's own opinion of UI logic and behavior for controls. Users do not get consistent experience when every app has it's own. This is the reason Apple and Microsoft have rules and guidelines for these while Android does not really enforce anything.

 

Can you expand on this ? Ive always seen this as a control issue solved by writing a toolbar, drawer, or other missing ui element. Ive seen this cliche quite a bit, but no one has ever backed it up with any substance.

Absolutely not. Apps with poor aesthetics should die. Has anyone ever complained about UI elements from unity ? As someone who uses both iOS and Android I have found the differences to be minimal. What they share is simplistic and intuitive design. That is what is important. The User does not care how we develop our UI, so long as it is quality.

 

I did not mean missing control types or such but non standard UI behavior. iOS apps should have controls, navigation, gestures, etc like you would expect them to be. I'm referring to the iOS app review guidelines and more specifically to sections about user interface and behavior. The rejections are based on how well the reviewer follows them but generally you can get the idea if you google around with say, section 10 rules and see how people have been rejected.

Like above I'm talking about platform specific look and functionality. Such as described here: https://developer.apple.com/library....html#//apple_ref/doc/uid/TP40006556-CH61-SW1

To get better idea, when you make an app with Unity and unless you don't mimic these your app will not have the support for platform action menus such as copy/paste/dictate around different places, features that people with disabilities need (accessibility features), slide back and forth in views, lists with gestures, your buttons, navigation bars, toggles wont look like they do in normal apps and so on...

 

That is fair. I agree that any serious release using uGUI should first include these features.

 

If unity chose to do this the farthest I could ever see them going is exposing a simple option to slow down the game loop to save battery a little bit. Anything beyond that is way outside of their focus. Frameworks that let their scope get too big become bloated and slower. When you become a jack of all trades you become a specialist in none.

Unity has enough problems and competition with UE4 in their core business to let themselves focus on anything else. If they did so it would be at their own peril.

 

If non-game applications are driven only through the gui, would it be possible to disable the game loop and just have events? Maybe enabling the game loop for simulation apps that have ongoing things that need a frame delta to show smoothly.

 

Drop to 30fps capped and do less logic in the same frame. Doing less logic == less battery, mobile cpus switch off as much as possible, same for the GPU.

It's not actually any different to having a 'power saving mode'. Just do less is the magic bullet.

 

I did that for an experiment in placing trees via raycast for a moving endless forest. I had a variable outside the loop keep track of the progress in placing trees and did it over several frames.

 

There are slightly more than a 4 options for app development. Tons. And the ones you listed not fully accurate.

1) native is always going to be more performant, devs will always use it. Especially for non games. Even for games, native is only slightly behind unity, and many of the biggest games are native. There tons of frameworks that support single code base. You aren't limited to objC/Java.

2) performance hit compared to what? Maybe slightly slower than uikit but Unity UI isn't even in the same ball park as web view. It's just not built for it. Try using unity to display this web page for example. Additionally, this isn't a new tech, it's been built in since day one. Many of the first apps were web view driven, it is literally a single line of code to invoke WebKit.

4) unity UI is good, for a game engine, it has a ways to go. No one would call it world class though. Maybe one day, but not just yet. But again, only for a game engine. Outside of unity (or any game engine) pretty much everything has more robust / rich / powerful UI tools. Html is more powerful.

Unity is a game engine. If you only know unity, sure you can build apps in it, but there are many faster, more efficient, better performant and easier ways to build them, and there always will be, because it is its own industry. No amount of fixing will allow unity to perform at the same level without a fundamental shift in design. Which is unrealistic because a) game engine b) no need, there are dozens of better options.

 

Yes. To disable the game loop, go to File > Quit. Then open a text editor, or other editor/tool that is not built specifically for making games and go nuts!

 

Yea, but that is hard and stuff. Unity should do it for me.

 

haha, but you guys don't even use scenes

 

True, but on my new project, we are going to use lights!

 

Notepad doesn't have a very good GUI builder

 

Try upgrading the contents of your chair.

 

Can you even reference a library from notepad? Or would you just be going off what you're pretty sure works until you can get something with a compiler / linker?

 

Dunno if it can. I use TM2 for everything, it doesn't link, but has Lang bundles (autocomplete and snippets) for most things, and for ones it doesn't I just write them if need them.

I just have my editor placed so I can see the unity footer. Whenever I save it updates the console and I can see warnings.

 

That's cool. But since I do most of my unity development on mac I actually like mono Man this veered off topic. Unity editor setting to disable / alter the main game loop for applications that don't need it: Yay or nay?

 

I only use a Mac, monodevelop is just too slow for me.

Disabling the main game loop is an oversimplification, and not a solution. It's a game engine. it handles things differently. Text alone is vastly different. Right tool for the right job and all that.

 

This. Turn off the game loop and everything breaks. Everything.

 

I guess I'll run into this problem when I start getting into larger projects.

Can't argue with that. It'd be a strange move for a game engine to try to function as less to cater to almost no one. If there was a way for games to benefit from this then maybe, but I don't see it lol.

Would events stop firing? You could still make tick tack toe without a loop

 

Except that rendering is part of that "loop".

 

The main loop should be where those events are firing from.

 

Pff, you can call camera.render after someone moves. I'm the noob here, yet I know this!

Darn. I always thought event hooks were magic.

 

To channel @Graham Dunnett ... In a car, one of the biggest impacts to fuel (energy) efficiency is the weight. Removing the motor would make it lighter and significantly reduce fuel consumption.

 

Without events, and movement what exactly would be calling that method?

 

Another thread? Part of me is tempted to throw together a quick experiment, despite knowing what will happen, where I infinite loop the main thread and try calling things from the secondary thread.

 

Me

I have no idea I don't even know what I'm doing on this thread. I use cordova for mobile apps.

 

Interesting experiment. Might be possible if you get tricksy. Remember that the unity api only runs on the main thread, I don't think you can communicate back to it from another thread, or do things that derive from unityengine. If you figure it out, please share, I have a use for it.

 

I use interns.

 

I've never been an intern I went straight from unemployed to entry level, starting tomorrow.

What use is this information to us? We can't mess with the main loop can we?

 

I am kind of curious what could be done if you locked the main thread up in an infinite sleep cycle, and only let it render based on events fired from another thread.

However this would mean all of your input would have to be generated somehow other then using Unity. Unity's input only fires off the next frame. You can't detect input mid frame.

So many hacks would be required to get this to work, I think the input constraints would quickly loose you any advantage gained by using Unity.

 

I dont think an all or nothing approach will work. Too many things are dependent on the main thread. Animations (for instance) are still needed to have a quality UI.

The reduction of frame rate was a good first step (~40% improvement). A good second step might be a slowing of the update loop and perhaps disabling of un-utilized features (physics, lighting). Combined with something like the MaterialUI toolkit, it might even be good enough to replace native development outright.

 

There is the problem. As I understand it spawned threads don't interact with the main thread. And the main thread is where the unity api is. You can spawn a thread, have it do something (as long as it doesn't use the unity api), store the results. Since you can't talk to the main thread directly from the worker thread, the main thread has to continually check for a complete flag/bool to know when it's done/ready. So you are back to square one, requiring the main loop.

 

My thoughts at this point are towards controlling when the main thread is allowed to run. I don't know how much you're able to access while it is effectively sleeping, but you could try native code to monitor for keyboard, mouse, and other events and when they occur simply unpause the main thread for a period of time.

 

It's not just the game loop, either. It's also other fundamental stuff like how rendering works, and that the audio system is far more complicated than you'd usually otherwise need for a GUI app.

For instance, game engines are optimised to constantly re-render the entire screen as quickly as possible, where (last time I learned about them, quite some time ago!) GUI frameworks are typically optimised to re-render only changed sections of the screen and only when changes occur.

So making a GUI app in a game engine is kind of un-optimising your presentation layer right from the start. Instead of updating bits of the screen as needed you're updating all of the screen all the time even when nothing is changing.

As far as I'm aware it's written right into the iTunes App Store submission and/or UI guidelines. From memory, Apple's guidelines say that games are one of few examples where it's a good idea to make up your own GUI styling, and that they'd prefer you stuck to theirs for most types of app.

Even with that aside, users generally expect controls to look more or less like equivalent controls they've used before. You're right that you could write your own replacements for missing functionality, and you could do it well enough to pass Apple's QA. But then it'll either look out of place on some/all platforms (yuck) or you've got to write equivalents for every platform (this brings back a lot of the work you're trying to avoid).

Can you implement the functionality? Absolutely. The real question is, how much time/cost will there be in meeting user expectations across devices? The answer to that answer will vary from project to project.

 

I was thinking something like this

Code (CSharp):

1. public bool shouldUpdate;
2.  
3. void Update () {
4.      while (!shouldUpdate) Thread.Sleep(100);
5.      // Do other update stuff
6. }

As indicated this is a bad idea, for a number of reasons. I'm just tossing around thoughts of "could we do it".

I'm well out of the "Is it a good idea" space. My thoughts on that are pretty much the same as my first post. Unity is not built for non-game-like applications.

 

How about manually rendering each control as necessary to a texture that is then drawn to the display every pass of the main thread? I can't imagine it would be that difficult to achieve with Unity's UI. Anything else might be a chore, but since we're discussing this anyway...

 

That's complicated by the fact that the UI is rendered through the same pipeline as the rest of the scene. I suspect that general approach is how modern hardware accelerated 2D GUIs are handled, though.

 

That is effectively what the UI/sprite system does in a sense, only more efficiently. (Well, when used properly). Atlasing makes it a single texture in memory, and is applied to the meshes, only drawing where needed. A single texture would be more expensive, as it would create a new texture, and have to draw the full screen. On top of that, you still have account for hit areas, and you would take a massive cpu hit for interactive/animated elements by redrawing the whole image.

Interestingly what you described is a common optimization trick in flash. Bliting everything to an image and updating it every frame. But flash is a highly optimized bitmap engine, and uses dirty rects to update only the parts of the image requiring it. And of course relies on the cpu for that. Great for desktops, not so much for devices.