Profile Tab What goes into (idle)

[Claude_N_]

Much to our surprise our game is spending 90% of its time in (idle).

Of course this only happens on the Android. :)

So I'm wondering, what can I take that to mean? What contributes to the seconds added into this figure?

We don't have any intentional timer functions that would lead to spending great amounts of time "waiting".

Could a function perhaps be defined incorrectly in such a way that it is not counted as itself, but contributes to (idle).

Just looking for any clues that would explain the dramatic difference between Desktop and Emulate (tab) vs this odd (idle) slow down on the actual device. Thinking that maybe if we new a little more about what goes into the accumulated (idle) figure we could know where to look in our code.

Thanks for any insight.

[PaulF_IntelCorp]

Any well-behaved app should be spending most of its time in idle, otherwise you risk running down the battery. The Emulate tab is not a good reference for how many CPU cycles are needed to run your app, there is a lot of other things going on behind the scenes in the Emulate tab that have nothing to do with the cycles consumed by your app, so watching the CPU cycles on your desktop machine is not an indicator of what the app will do on a real device.

Does your app work properly on the device? Is it running slowly or running properly? Spending 90% of time in idle is not an indication that there is something wrong with your app, it simply means there are no events to handle or that the events are being handled efficiently.

Please see this document for more details: https://software.intel.com/en-us/xdk/docs/intel-xdk-debug-and-test-overview

[Claude_N_]

Hello Paul,

App renders properly. Looks gorgeous actually.

But it is very slow.

On desktop and in emulate the ftp is 30+

On the Galaxy Tablet it is 1 fps maybe 2 fps.

Which is why my question was generated. If the app is truly idle 90%, then why the low frame rate. Which got me to thinking that perhaps idle might not mean doing nothing or "at rest".

btw, thanks for the link.

[PaulF_IntelCorp]

Are you building with Crosswalk? If you are building to run on the builtin webview you may see some dismal frame rates. Also, see this doc page for a little bit of info regarding the difference between the desktop and real devices: https://software.intel.com/en-us/xdk/docs/dev-emulator#devem_gui

If you are using Crosswalk, which version? Try building against Crosswalk 7 and against Crosswalk 12 and let me know your results.

[Claude_N_]

Definitely running Crosswalk.

Until further notice, I'm convinced Crosswalk is the way to go. I can't stand the idea of having to deal with variable native webviews.

I have tried Crosswalk 10 and Crosswalk 12. Have not tried 7 yet. I will give you results as soon as I can run the experiment. However, it might be a week before I get those results. Leaving soon for 7 days afd (away from desk).

If all goes well, I will have those results. However, in another thread I am following down a different problem. I can use debug and profile on the device -- slow but looks great. However, when I build the app and download the apk the canvas is blank. SWATI S. (Intel) has offered to let me send a cut down version of the app so that they can debug what is happening with the apk installed version.

Maybe that will shed light on this other issue as well. Or I could cc you the same project and you could poke it with a stick. :)

In any case I much appreciate the help that comes through this forum.

By the way, I installed XDK on my friend's computer today. I noticed that at every speed bump or pothole XDK had valuable contextual help. An amazing amount of effort has gone into making XDK accessible. Don't know if the dev team gets enough props for that.

Regards,

[Andrey_M_Intel]

Did you have a chance to try the crosswalk 7? Latest chromium versions, as well WebView built on top of them has performance issues in skia - the drawing library.

As for performance optimization - I would recommend start any evaluation from the new XDK feature - Resource Monitor. It is a new feature available in the Profile Tab. If you find out that your app is works slowly you need to go to the profiling stage. The criteria if app works slow or not is simple - low fps with high CPU load on the same time. For further profiling of games I would recommend to use CDT Time line and collect the stack information for further analysis what happens inside the frame. If there are problems in JavaScript or during drawing by WebView.

The CPU Profile make sense to use when you know that JavaScript a hot part and you have some significant continuous work in JavaScript, that is not a case of the games.On the other hand your described picture looks very suspicious. If you have FPS=2, then it should not have 90% in the idle stage. I have suspicious that the problem is in the Galaxy Tab 4 7'3G. I tried HTML5 apps on it and they work much slower than on other devices. If it is a problem of the device and HTML5 engine (aka WebView) coexistence - you cannot do anything here.

And one more question - do you use 3rd party game engine? Usually it's very hard to understand what goes wrong with 3rd party engines if you are not a developer of them. Sometimes it's make sense to ask questions directly from the game engine developers.

[Claude_N_]

Hello,

Thank you for the response.

Much of your reply makes sense and we are trying the various angles.

We have written the game engine ourselves. And have had some success in getting the FPS up. WebGL on mobile is extremely tricky. We are using many webgl tricks that are helping to improve the frame rate.

We definitely want to keep pursuing this avenue of research to make it even better.

But, right now our great concern is that when we do a build the app does not display the canvas at all.

On a separate thread we were asked to provide a cut-down version of the app and send it by private message.

It has been three weeks since sending in the zipped project as requested. Is this a normal waiting period?

We are totally stopped dead in our tracks.

Our app works in the debug and profile tabs.

However, when we do a build, download, unzip, upload arm to server, download to phone, then test .... the canvas is black.

Since the debug and profile work but the build does not work, it seems that:

1) perhaps those two tabs are not providing an accurate depiction of what happens with a build.

2) or, there is a glitch in the build process.

3) or, there is some other as yet unaccounted for error happening.

We are not equipped to debug the apk download version. That is one of the reasons I love the XDK and its debug tab.

Any clues on how to proceed? Sorry for the thread jump and thread hijack. But, it has been a couple weeks with no response on the other thread.

Regards,

p.s. thanks again for the great suggestions on new ways to tackle the FPS issue.

[PaulF_IntelCorp]

If you are not seeing a response to the PM on the other thread, you may need to "kick the thread" with a new post. We deal with a lot of threads on a daily basis, so it's easy to get behind. Our support team has many other tasks we must handle that are outside of the forum, none of us is able to dedicate 100% of our time to monitoring the forum.

Regarding the various XDK tabs, if you are building for Crosswalk you should either be debugging built apps on your device using remote CDT (set "debuggable" to "true" in the additions.xml file) or using the Debug tab. The Debug tab uses a matching version of Crosswalk to host your app when you debug. If you are using any third-party plugins, they will not be debuggable using the Debug tab (this will be possible in a future version of the XDK). In that case, you need to build your app with "debuggable" equal to "true" and then use remote CDT (see first link in this paragraph).

My recommendation is that you try debugging the built app using remote CDT.

Note: you can only perform the profiling that Andrey referred to using the Profile tab, you cannot do that using remote CDT and a built app.

[Andrey_M_Intel]

I have investigated the app. I used approach from the Paul's link:  debugging built apps on your device using remote CDT (set "debuggable" to "true" in the intel.xdk.additions.xml file). After that I built apk and was able to connect to your app using Chrome remote debuging capabilities. The problem is in the upper and lower cases of characters in the resource names. After renaming of 

www/worlds/ANDYBRDO.WGW -> www/worlds/andybro.wgw
www/worlds/MODELXX.WGW -> www/worlds/modelxx.wgw
www/models/lamp57.png -> www/models/LAMP57.PNG
www/models/lamp57s.png -> www/models/LAMP57S.PNG
www/gfx/cement11.png ->www/gfx/CEMENT11.png 
www/gfx/cobbl01b.png -> www/gfx/COBBL01B.png 

as well there is no file www/model/NONAME.png at all, but it is tried to be loaded

I started to see the canvas and was able to walk in the scene. There might be more changes in the name, I am not sure I have fixed all of issues.

And the performance doesn't look awful, yes, the FPS is low enough, our Resource Montor points that usually it is lower than required 25 FPS, but it is not 2. And I collected CPU profile data and program (native of crosswalk/chromium) takes 60%, idle is ~20%. That means that almost all resources go to the drawing of the scene.

[Claude_N_]

Audrey, Thanks for looking into this.

Today's agenda is to get CDT working. That is an awesome tool. And it looks like it will be very necessary since the debug tab is obviously not reproducing the working environment. A little surprising to me since the app is running on a device. But this file case sensitivity definitely did not rear its ugly head until the build. Working in linux I'm used to case sensitivity. But since the app worked fine in the debug tab, I thought android was like windows and it just didn't care about case. Lesson learned.

Are there other known idiosyncrasies between the debug tab and the actual build? 

Thanks again.

[Andrey_M_Intel]

Really there should not be difference between Debug tab and standalone build. We are investigating why such issue was not repro in case of Debug tab and we will fix this. Your application must not work in Debug tab also.

Thus, the usage model should be the same for your further development. It's better to use Debug tab because it is faster and makes the development cycle shorter that is important for development. And it unifies the development for the Android and iOS - you just need to plug different devices and develop from the same Debug tab.

[PaulF_IntelCorp]

Thank you, Andrey! :)