Moving multiple native elements causes considerable performance loss

[danielr0]

When I add one or more native elements to a scene and attempt to move them, they’re inserted into the scene and the scene transitions to the devices view, the performance of my test devices (an sgs3 and an sgs7) both drop from 60 to around 25 fps. When the scene is done moving, the fps is back to a consistent 60 again.

I’ve only tested with native.newTextField and native.newMapView so far.

The other issue, of which I imagine is connected, is that the native elements lag behind the group they’ve been inserted into when that group moves.

Is there anything I can do to improve performance during translations?

[rob]

Actually this is fully understandable. Native objects are not part of the OpenGL layer. You get no graphics card acceleration with them. Lua also has to talk to the native controls in a different way. Basically we move native items manually for you, where as the bitmaps move as a harmonious group. Drawing textFields is 1000x the cycles to draw a bitmap.

Think of it like this:  All of your display objects in a group is like a bunch of people piled in a van. Your native objects are tractor-trailer trucks in lanes beside you. When you move your van, all of your passengers move efficiently, but you have to communicate with the drivers of the other trucks letting them know you’ve moved and they need to move with you.

There isn’t much can be done about this. Getting 25fps is probably pretty good given how costly native objects are.

[danielr0]

That’s what I suspected.

Is there any way I can sneakily deal with this?

It’s going to be harder to deal with the map view, but the textfields I can at least pretend to have transition into the scene.

I was thinking of having a display.newText object with a rect behind it move into the scene, and then in the scene’s show “did” phase I’ll replace them with the native elements (which I created out of view in the scene’s create function).

The only issue now, is trying to figure out how android (and eventually I need to figure ios too) renders the textfields.

I noticed the rect is the exact same, but the text itself is much smaller, like it has padding on the inside. Is there a way to know the exact fontSize of the textfields?

[rob]

I wouldn’t try and render any fake text. Just drop a rectangle behind where the native.newTextField() is going to be and maybe style it to look like it will. For iOS it’s just a white box with a thin rounded rect very light gray border around it. Android text fields have changed over the years.

For the mapView do the same thing. I always create a middle-gray box the size of the mapView and drop it under where the mapView will go.

For me, I create the native.* objects in scene:show()'s did phase after it’s fully on screen. Then I destroy them in scene:hide()'s “will” phase just before it heads off screen and your display.newRect()'s are there to provide the transition.

Rob

[danielr0]

Thanks Rob,

I’d really like to be able to show the placeholder text though, so having this as a bitmap text object too would be really nice.

For now though I’ve created a wrapper  class with load and unload functions that I call in the show.did and hide.will stages. Makes it a little easier to handle these native objects.

[rob]

Actually this is fully understandable. Native objects are not part of the OpenGL layer. You get no graphics card acceleration with them. Lua also has to talk to the native controls in a different way. Basically we move native items manually for you, where as the bitmaps move as a harmonious group. Drawing textFields is 1000x the cycles to draw a bitmap.

Think of it like this:  All of your display objects in a group is like a bunch of people piled in a van. Your native objects are tractor-trailer trucks in lanes beside you. When you move your van, all of your passengers move efficiently, but you have to communicate with the drivers of the other trucks letting them know you’ve moved and they need to move with you.

There isn’t much can be done about this. Getting 25fps is probably pretty good given how costly native objects are.

[danielr0]

That’s what I suspected.

Is there any way I can sneakily deal with this?

It’s going to be harder to deal with the map view, but the textfields I can at least pretend to have transition into the scene.

I was thinking of having a display.newText object with a rect behind it move into the scene, and then in the scene’s show “did” phase I’ll replace them with the native elements (which I created out of view in the scene’s create function).

The only issue now, is trying to figure out how android (and eventually I need to figure ios too) renders the textfields.

I noticed the rect is the exact same, but the text itself is much smaller, like it has padding on the inside. Is there a way to know the exact fontSize of the textfields?

[rob]

I wouldn’t try and render any fake text. Just drop a rectangle behind where the native.newTextField() is going to be and maybe style it to look like it will. For iOS it’s just a white box with a thin rounded rect very light gray border around it. Android text fields have changed over the years.

For the mapView do the same thing. I always create a middle-gray box the size of the mapView and drop it under where the mapView will go.

For me, I create the native.* objects in scene:show()'s did phase after it’s fully on screen. Then I destroy them in scene:hide()'s “will” phase just before it heads off screen and your display.newRect()'s are there to provide the transition.

Rob

[danielr0]

Thanks Rob,

I’d really like to be able to show the placeholder text though, so having this as a bitmap text object too would be really nice.

For now though I’ve created a wrapper  class with load and unload functions that I call in the show.did and hide.will stages. Makes it a little easier to handle these native objects.