testing on iOS (unity3d)
Here are the results of some testing. Generally things seem to look nice and are responsive enough- maybe a little on the sluggish side. I am using Unity 4.3.4. ipad2 w/ 7.1, ipod4 w/ 6.3
1. (bug) In the Control Gallery scene, try the TextBox and editable ComboBox. The Caret skips to the far left, even though the characters are being appended on the right. Maybe all text controls have this problem.
2. (questionable) The ControlGallery scene uses ~ 60% of cpu on the ipad and ~70% of cpu on the ipod, according to xcode instruments. By comparison an empty scene for Unity uses about 20% of cpu. I picked the ControlGallery for this test, specifically because there are no animations. There are dozens of controls, yes, but if player is not interacting with the UI, why is 1/2 of a core being used constantly? I also tried setting Application.targetFrameRate = 30 but it didn't lower the cpu usage. On mobile it's really important not to waste the user's battery, so I am wondering if why so much cpu usage at idle with no interactions and no animations?
3. (feedback) In the Control Gallery scene, the disclosure triangles in the outline view, and some checkboxes, etc, are generally not usable at all. It takes many tries to hit them on touch screen. I guess because this scene was not designed with touch screen in mind.
4. (question) Upon launch I see in the unity log "Masking disabled because Stencil Buffer is not present. Use a 24-bits DepthBuffer to activate it." in the log. This is weird because my build settings definitely have use 24-bit depth buffer turned on. Do you know anything about this? As far as I can tell the scene is rendering OK. This may be a Unity 4.3 issue.
5 . (uhoh!) Just by tapping and swiping around in the Control Gallery scene I managed to generate a hard crash (EXC_BAD_ACCESS). I was just looking at the Shapes : Butterfly, Lion, Tiger, Time, Tux, etc.
noesistest`Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const at FrameworkTemplate.cpp:204:
0x10d1868: push {r4, r5, r7, lr}
0x10d186a: add r7, sp, #0x8
0x10d186c: sub sp, #0x4
0x10d186e: mov r5, r0
0x10d1870: movs r0, #0x0
0x10d1872: str r0, [sp]
0x10d1874: mov r4, r1
0x10d1876: ldr r0, [r5, #0x24]
0x10d1878: cbz r0, 0x10d188c ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 36 at FrameworkTemplate.cpp:211
0x10d187a: ldr r1, [r0]
0x10d187c: mov r2, sp
0x10d187e: ldr r3, [r1, #0x18]
0x10d1880: mov r1, r4
0x10d1882: blx r3
0x10d1884: cmp r0, #0x1
0x10d1886: bne 0x10d188c ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 36 at FrameworkTemplate.cpp:211
0x10d1888: ldr r0, [sp]
0x10d188a: b 0x10d189e ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 54 at FrameworkTemplate.cpp:217
0x10d188c: ldr r0, [r5, #0x1c]
0x10d188e: cbz r0, 0x10d189a ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 50 at FrameworkTemplate.cpp:216
0x10d1890: ldr r1, [r0]
0x10d1892: ldr r2, [r1, #0x2c]
0x10d1894: mov r1, r4
0x10d1896: blx r2
0x10d1898: b 0x10d189e ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 54 at FrameworkTemplate.cpp:217
0x10d189a: bl 0x108016c ; Noesis::Gui::DependencyProperty::GetUnsetValue() at DependencyProperty.cpp:154
0x10d189e: add sp, #0x4
0x10d18a0: pop {r4, r5, r7, pc}
1. (bug) In the Control Gallery scene, try the TextBox and editable ComboBox. The Caret skips to the far left, even though the characters are being appended on the right. Maybe all text controls have this problem.
2. (questionable) The ControlGallery scene uses ~ 60% of cpu on the ipad and ~70% of cpu on the ipod, according to xcode instruments. By comparison an empty scene for Unity uses about 20% of cpu. I picked the ControlGallery for this test, specifically because there are no animations. There are dozens of controls, yes, but if player is not interacting with the UI, why is 1/2 of a core being used constantly? I also tried setting Application.targetFrameRate = 30 but it didn't lower the cpu usage. On mobile it's really important not to waste the user's battery, so I am wondering if why so much cpu usage at idle with no interactions and no animations?
3. (feedback) In the Control Gallery scene, the disclosure triangles in the outline view, and some checkboxes, etc, are generally not usable at all. It takes many tries to hit them on touch screen. I guess because this scene was not designed with touch screen in mind.
4. (question) Upon launch I see in the unity log "Masking disabled because Stencil Buffer is not present. Use a 24-bits DepthBuffer to activate it." in the log. This is weird because my build settings definitely have use 24-bit depth buffer turned on. Do you know anything about this? As far as I can tell the scene is rendering OK. This may be a Unity 4.3 issue.
5 . (uhoh!) Just by tapping and swiping around in the Control Gallery scene I managed to generate a hard crash (EXC_BAD_ACCESS). I was just looking at the Shapes : Butterfly, Lion, Tiger, Time, Tux, etc.
noesistest`Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const at FrameworkTemplate.cpp:204:
0x10d1868: push {r4, r5, r7, lr}
0x10d186a: add r7, sp, #0x8
0x10d186c: sub sp, #0x4
0x10d186e: mov r5, r0
0x10d1870: movs r0, #0x0
0x10d1872: str r0, [sp]
0x10d1874: mov r4, r1
0x10d1876: ldr r0, [r5, #0x24]
0x10d1878: cbz r0, 0x10d188c ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 36 at FrameworkTemplate.cpp:211
0x10d187a: ldr r1, [r0]
0x10d187c: mov r2, sp
0x10d187e: ldr r3, [r1, #0x18]
0x10d1880: mov r1, r4
0x10d1882: blx r3
0x10d1884: cmp r0, #0x1
0x10d1886: bne 0x10d188c ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 36 at FrameworkTemplate.cpp:211
0x10d1888: ldr r0, [sp]
0x10d188a: b 0x10d189e ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 54 at FrameworkTemplate.cpp:217
0x10d188c: ldr r0, [r5, #0x1c]
0x10d188e: cbz r0, 0x10d189a ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 50 at FrameworkTemplate.cpp:216
0x10d1890: ldr r1, [r0]
0x10d1892: ldr r2, [r1, #0x2c]
0x10d1894: mov r1, r4
0x10d1896: blx r2
0x10d1898: b 0x10d189e ; Noesis::Gui::FrameworkTemplate::FindNodeResource(Noesis::Gui::IResourceKey*) const + 54 at FrameworkTemplate.cpp:217
0x10d189a: bl 0x108016c ; Noesis::Gui::DependencyProperty::GetUnsetValue() at DependencyProperty.cpp:154
0x10d189e: add sp, #0x4
0x10d18a0: pop {r4, r5, r7, pc}
Re: testing on iOS (unity3d)
First at all, thanks for your feedback!
1. NoesisGUI is not specially optimized for static GUI. Although this may sound strange, we think that other GUI products are doing this incorrectly. Optimizing the good case is not a good idea, yes, you can be very good at rendering static geometry but as soon as you start to move panels, launch animations your framerate drop to 1fps. NoesisGUI is optimized for dynamic geometry, this usually means that moving and animating controls is generally fast. Of course static geometry will be always faster but not an order of magnitude.
2. Unity is not optimized for saving user's battery. We have an incremental algorithm that can detect when a new frame is identical to the previous one. In this scenario we could stop rendering because the screen content is valid. As far as I know this is not possible in Unity. Can be done directly with out C++ API (and in the future we will improve this algorithm to only update parts of the screen that have changed).
Probably related to our noesisGUI style, it is not optimized for mobile. We are working to solve this in v1.2.Here are the results of some testing. Generally things seem to look nice and are responsive enough- maybe a little on the sluggish side. I am using Unity 4.3.4. ipad2 w/ 7.1, ipod4 w/ 6.3
Could you please file a bug about this?1. (bug) In the Control Gallery scene, try the TextBox and editable ComboBox. The Caret skips to the far left, even though the characters are being appended on the right. Maybe all text controls have this problem.
There are two involved parts here:2. (questionable) The ControlGallery scene uses ~ 60% of cpu on the ipad and ~70% of cpu on the ipod, according to xcode instruments. By comparison an empty scene for Unity uses about 20% of cpu. I picked the ControlGallery for this test, specifically because there are no animations. There are dozens of controls, yes, but if player is not interacting with the UI, why is 1/2 of a core being used constantly? I also tried setting Application.targetFrameRate = 30 but it didn't lower the cpu usage. On mobile it's really important not to waste the user's battery, so I am wondering if why so much cpu usage at idle with no interactions and no animations?
1. NoesisGUI is not specially optimized for static GUI. Although this may sound strange, we think that other GUI products are doing this incorrectly. Optimizing the good case is not a good idea, yes, you can be very good at rendering static geometry but as soon as you start to move panels, launch animations your framerate drop to 1fps. NoesisGUI is optimized for dynamic geometry, this usually means that moving and animating controls is generally fast. Of course static geometry will be always faster but not an order of magnitude.
2. Unity is not optimized for saving user's battery. We have an incremental algorithm that can detect when a new frame is identical to the previous one. In this scenario we could stop rendering because the screen content is valid. As far as I know this is not possible in Unity. Can be done directly with out C++ API (and in the future we will improve this algorithm to only update parts of the screen that have changed).
Yes, this sample was done before noesisGUI was ported to iOS and Android. We are working to improve this.3. (feedback) In the Control Gallery scene, the disclosure triangles in the outline view, and some checkboxes, etc, are generally not usable at all. It takes many tries to hit them on touch screen. I guess because this scene was not designed with touch screen in mind.
Yes, this has been reported by more users. Unity is incorrectly reporting us that there is not StencilBuffer active. I think we should remove this warning. Taking note.4. (question) Upon launch I see in the unity log "Masking disabled because Stencil Buffer is not present. Use a 24-bits DepthBuffer to activate it." in the log. This is weird because my build settings definitely have use 24-bit depth buffer turned on. Do you know anything about this? As far as I can tell the scene is rendering OK. This may be a Unity 4.3 issue.
Please, report a file for this problem. Will be fixed a soon as possible.5 . (uhoh!) Just by tapping and swiping around in the Control Gallery scene I managed to generate a hard crash (EXC_BAD_ACCESS). I was just looking at the Shapes : Butterfly, Lion, Tiger, Time, Tux, etc.