native.newTextField() slow render?

hi.

when i use:

local someField = native.newTextField( 0, 0, 220, 36 ) someField.x = 200 someField.y = 200

i always notice for a split sec the text box moving from 0 to the correct position. when i create other objects this doesn’t happen. i’m talking in a device not in simulator. i know this is actually going on because i first create at 0, 0 position then i move it to 200, 200 but i thought the processor/code was good enought to move it without human notice.

it this function that slow? my device is a nexus 7 2013. i bet there are a lot of slower devices out there, so this worries me.

I know i can use:

local someField = native.newTextField( 200, 200, 220, 36 )

this works fine in device, but if i put the variable someField in a group and that group is not in 0, 0 coordenates, the same happens…the moving box, so huston we have a problem.

Only me notice this? I can’t be alone out there :slight_smile:

Best regards,

Carlos.

I’ve worked extensively with text field and I’ve never seen this behavior. Which corona build are you using?

2015.2610

i only notice this in the device (nexus 7 2013 with lollipop).

I would think it might be Lollipop.  I put it on my 1st Gen Nexus 7 and I can barely use it.  This is the first complaint I’ve heard about it and we’ve not made any changes in a while around this.

Rob

This is very strange, because to be honest I would think Corona only updates the display when a code block is processed in its entirety.

i worked alot with textBoxs when i did a form creator from a json file and a quiz builder, and never had this problem.

i will make more tests when i’ve time. now i need to move to other problems :/. i correct this problem by adding x,y coordenates that my group had…and after i insert the textobox to the group, i subtract that same amount. now i don’t see the jump. l i know this is not the correct way to do. mental note:“revise code when ive time” (parker lewis can’t lose anyone remember?)

best regards to all

Carlos.

I’ve worked extensively with text field and I’ve never seen this behavior. Which corona build are you using?

2015.2610

i only notice this in the device (nexus 7 2013 with lollipop).

I would think it might be Lollipop.  I put it on my 1st Gen Nexus 7 and I can barely use it.  This is the first complaint I’ve heard about it and we’ve not made any changes in a while around this.

Rob

This is very strange, because to be honest I would think Corona only updates the display when a code block is processed in its entirety.

i worked alot with textBoxs when i did a form creator from a json file and a quiz builder, and never had this problem.

i will make more tests when i’ve time. now i need to move to other problems :/. i correct this problem by adding x,y coordenates that my group had…and after i insert the textobox to the group, i subtract that same amount. now i don’t see the jump. l i know this is not the correct way to do. mental note:“revise code when ive time” (parker lewis can’t lose anyone remember?)

best regards to all

Carlos.

I had a similar problem with the Mac simulator, Windows simulator, iOS and Android.

I was able to fix it by removing my adjustments to the .anchorX and .anchorY properties, and just positioning it relative to the default anchor point.

It’s because you’re moving the TextField/TextBox just after you’ve created it.  So, what you’re seeing is that for a blink of a second the TextField is appearing at the position that you’ve initialized it to upon creation and then it quickly moves to where you want it to be after adjust the field’s x/y properties.

As far as I know, this issue can only happen on Android and Windows/Win32.

It has nothing to do with speed or it being slow and more of the nature of how their UI frameworks work.

On Android, it’s because Lua and native UI run on separate threads (Lua runs on Android’s OpenGL thread which performs all hardware accelerated rendering).  So, every native UI operation you perform in Lua must be posted and queued onto the UI thread to be done a split second later.  And synchronizing between the Lua thread and the UI thread would be a terrible mistake because that would cause huge performance issues.

On classic Win32 apps such as the Windows Corona Simulator, there is no such thing as composite frame based rendering of its native Win32 UI.  You can literally watch its native UI redraw itself for every UI change you make within the same frame.  It’s an old early 90s UI framework and that’s just how it works.

So, the best cross-platform solution is to do one of the following:

  • Set the TextField’s position to what you want it to be upon creation.

  • Create the TextFeild offscreen, make you adjustments, and then move it onscreen via the translate() function.  (Set’s x/y in 1 shot.)

thanks for the clarification, Joshua.

I had a similar problem with the Mac simulator, Windows simulator, iOS and Android.

I was able to fix it by removing my adjustments to the .anchorX and .anchorY properties, and just positioning it relative to the default anchor point.

It’s because you’re moving the TextField/TextBox just after you’ve created it.  So, what you’re seeing is that for a blink of a second the TextField is appearing at the position that you’ve initialized it to upon creation and then it quickly moves to where you want it to be after adjust the field’s x/y properties.

As far as I know, this issue can only happen on Android and Windows/Win32.

It has nothing to do with speed or it being slow and more of the nature of how their UI frameworks work.

On Android, it’s because Lua and native UI run on separate threads (Lua runs on Android’s OpenGL thread which performs all hardware accelerated rendering).  So, every native UI operation you perform in Lua must be posted and queued onto the UI thread to be done a split second later.  And synchronizing between the Lua thread and the UI thread would be a terrible mistake because that would cause huge performance issues.

On classic Win32 apps such as the Windows Corona Simulator, there is no such thing as composite frame based rendering of its native Win32 UI.  You can literally watch its native UI redraw itself for every UI change you make within the same frame.  It’s an old early 90s UI framework and that’s just how it works.

So, the best cross-platform solution is to do one of the following:

  • Set the TextField’s position to what you want it to be upon creation.

  • Create the TextFeild offscreen, make you adjustments, and then move it onscreen via the translate() function.  (Set’s x/y in 1 shot.)

thanks for the clarification, Joshua.