30% performance loss by multitouch in empty app

Unity Engine
1

We experience a significant performance drop (up to 30%!) by plain multitouching in an empty Unity app across different devices and platforms. In most cases the framedrop is around 10% and may not be noticable in real world applications but on our worst case device (Lumia 525) it is about 30%. This bug was already reported on 2016-03-15 (779931) and also confirmed by Unity on 2016-07-03. I sent a bump on 2017-11-29 but there was no further update since.

1024×768 474 KB

(Caption: The frame graph clealry drops when touching the device)

The setup for this test was a simple scene with a few plane meshes, so the renderer got some work to do (~100k tris), and apart from the FPS counter UI no other script are used.

Every tests was performed with the following user actions:

  1. no touch
  2. single touch without moving
  3. single touch with lots of movement
  4. multitouch with three fingers without moving
  5. multitouch with lots of movement
    whereas the framerate drops with every more complex multitouch action.

The following videos were recorded using Unity 5.4.0b9 but this issue is also reproducible in 5.3.3f1:
Nokia Lumia 520 (also reproduced on 5.4.0.b21)
Asus Nexus7 Tablet (2013)
Nokia Lumia 550
Microsoft Surface 2
Nokia Lumia 925
Samsung Galaxy S4

Test results in detail:

Nokia Lumia 520, Windows Phone 8.1: clear and significant framedrop

                         FPS min  FPS max  % drop   visual FPS
no touch                        54       56         constant brownish orange
static singletouch              47       49  12.73% constant orange
moving singletouch              47       49  12.73% constant orange
static multitouch (3)           40       45  22.73% constant redish orange
moving multitouch (3)           35       40  31.82% constant redish orange

Asus Nexus7 Tablet (2013), Android 6: clear framedrop

                         FPS min  FPS max  % drop   visual FPS
no touch                        76       77         constant greenish yellow
static singletouch              74       77   1.31% constant greenish yellow
moving singletouch              68       74   7.19% constant orange
static multitouch (3)           70       75   5.23% constant brownish orange
moving multitouch (3)           65       70  11.76% constant orange

Nokia Lumia 550, Windows Phone 10: clear framedrop

                         FPS min  FPS max  % drop   visual FPS
no touch                        27       28         constant brownish orange
static singletouch              27       28   0.00% constant brownish orange
moving singletouch              24       26   9.09% constant orange
static multitouch (3)           24       26   9.09% constant orange
moving multitouch (3)           24       26   9.09% constant orange

Microsoft Surface 2, Windows RT 8.1: framedrop is not constant but clearly visible

                         FPS min  FPS max  % drop   visual FPS
no touch                       119      120         constant greenish yellow
static singletouch             119      120   0.00% constant greenish yellow
moving singletouch             119      120   0.00% constant greenish yellow
static multitouch (3)          114      119   2.51% greenish yellow with a few orange stripes
moving multitouch (3)          107      115   7.11% greenish yellow with more orange stripes

Samsung Galaxy S4, Android 5: normal FPS are a bit erratic, but the frame drop can be clearly identified by the additional redish bursts of stripes

                         FPS min  FPS max  % drop   visual FPS
no touch                        80       80         brownish orange
static singletouch              70       70  12.50% brownish orange with orange stripes
moving singletouch              55       55  31.25% redish orange with brownish stripes
static multitouch (3)           70       70  12.50% brownish orange with orange stripes
moving multitouch (3)           55       55  31.25% redish orange with brownish stripes

Nokia Lumia 925, Windows Phone 8.1: clear framedrop

                         FPS min  FPS max  % drop   visual FPS
no touch                        86       90         constant greenish yellow
static singletouch              86       90   0.00% constant brownish orange
moving singletouch              75       82  10.80% constant brownish orange
static multitouch (3)                               missing
moving multitouch (3)                               missing

The FPS counter used is a paid assetstore extension called “Simple FPS Counter” and therefore was not attached. Unfortunately it is also no longer available in the assetstore thus you need to integrate your own FPS counter.

2940238–217587–scenefile.zip (12.4 KB)

2

bump

Anyone from the Unity side interested in fixing this crucial performance killer?

Just in case you wonder, e.g. Lumia 520 still covers 10% of ALL WINDOWS PHONE/MOBILE devices (yes, including Win 10 mobile). See for yourself: http://blog.adduplex.com/2016/10/adduplex-windows-device-statistics-report-october-2016.html

I have also seen test cases, where a 58 FPS scene goes down below 30 FPS – just because of touching the screen(!!!). And as stated above, the issue occurs across all kinds of devices, not only Windows Phone.

3

I gave it a quick spin…

Two observations:

  1. XAML seems to use a lot of CPU when you’re touching the screen:

Unfortunately this one is outside our control. Did you try D3D project type instead?

  1. OnGUI is expensive when there’s loads of touch events, since for each touch event OnGUI is called every time:

This one is directly affected by your scripts: it seems that drawing that graph with GUI.DrawTexture is expensive when you’re doing it multiple times a frame. Do you have a lot of OnGUI functions in your game?

4

Thanks for the reply, we’ll test your feedback.
D3D … does that mean, most native (C#) extensions won’t work, right?
E.g. Vungle and/or IAP?

5

IAP has no dependency on XAML. No idea about Vungle.

6

We don’t use OnGUI anywhere in our actual game. In the demo app it is used by one component in one object to draw the FPS graph ( @ : see FPSCounterGUI in the fogbugz 779931 attachment). We could redo the tests with a new FPS counter component, but the reason why we made these tests in the first place was because we experienced a performance drop in our actual game.

7

Regarding D3D and XAML: It seems you cannot change that for W8.1 in Unity 5.5 anymore?I remember that this used to be possible?

And whats the default build type for W8.1?
I didn’t find the explanation for this setting in the docs …

Thanks!

8

Yeah I saw. The drop in performance in that sample is due to XAML doing stuff and consuming a lot of CPU.

Windows 8.1 uses XAML… There’s no way to build D3D application from Unity with Windows 8.1 unfortunately due to a historical decision we made in 5.0 or so when we looked that nobody used D3D build type. We added it back to Windows 10 since Microsoft requested it.

However, you should theoretically be able to take App.cs from D3D template and replace the source files in exported VS solution at least for testing to see if XAML is the culprit. There’s nothing technical preventing D3D app type from working on Windows 8.1.

9

@Swapping the Template:
Replacing the App.cs for desktop seems to work, but phone doesnt, it crashes somewhere during initialization:

GfxDevice: creating device client; threaded=1

Direct3D:

  Version:  Direct3D 11.0 [level 9.3]

  Renderer: Qualcomm Adreno 305 (WDDM v1.2) (ID=0x30303330)

  Vendor:  Qualcomm

  VRAM:  197 MB

CreateSwapChainForCoreWindow failed with error 0x887a0004
(Filename: C:/buildslave/unity/build/Runtime/GfxDevice/d3d11/D3D11Context_Metro.cpp Line: 445)

What I did:

  • remove App.xaml+cs and MainPage.xaml+cs
  • add App.cs
  • comment out WIn10 specific calls in App.cs (something with the status bar)

Did I miss something?

10

Bump

11

Bump

12

Input performance has gotten better when using IIS ( Users complaining that mouse doesn't work anymore - Unity Engine - Unity Discussions ).

We will not do any further investigation on other platforms.