Poor performance in scrollView

Solar2D Widgets
#1

I added a scrollView to my game yesterday for selecting levels. It’s a simple grid of ~100 buttons, and I’ve implemented the documented workaround to pass move events from the buttons up to the scrollView.

But the scrollView’s perf is not great on my iPhone 6. Scrolling around feels a little laggy, much worse than the native scrolling controls in iOS, and worse than the perf of swipeable objects I’ve implemented in Corona.

I tried building a scrollview with just a single button in it to test perf and it seems to be the same.

Is this a known issue? Anything I can do to make the scrollView feel better?

#2

My scrollviews have about 30-100 items in them – mostly text but some large images and graphics – and they’re fine on my iPhone 6 Plus using 2015.2638. More precisely, I just checked and they may not be quite as fluid as a native app, but you would have to look hard to tell the difference. 

Because you didn’t post what build you’re using or other details, you may not get the help you’re looking for. You also didn’t say what the performance of Corona’s sample Scrollview project looks like on your device. Some video may be helpful too.

#3

Thanks. I just upgraded to 2015.2646 and it’s noticeably better, but still much worse than the native controls. It feels *OK* on device, but worse in the simulator.

If I can find some spare time I’ll see if I can put together a min-repro.

#4

Alright, I loaded up the Widget Demo sample and changed the background element to be tall enough to actually scroll (changed the height from 512 to 5120) and on my iPhone 6 it is not very good. Fast swipes and such are totally missed, it’s really hard to scroll any distance at a time. That said, even though the sample feels bad to use, it is rendering smoothly.

As per my own app, I have a scrollview with ~100 button widgets inside of it. The scrollview is defined like this:

levelSelectGroup = widget.newScrollView({ left = 0, top = titleBarHeight, width = display.contentWidth, height = display.contentHeight - titleBarHeight, scrollWidth = display.contentWidth, horizontalScrollDisabled = true, hideBackground = true })

and I have a loop that generates button widgets and inserts them like this:

buttons[id] = widget.newButton({ label = tostring( puzzleData.index ), id = id, left = xOffset, top = yOffset, onEvent = handleLevelSelect, emboss = false, width = buttonWidth, height = levelButtonHeight, font = native.systemFont, fontSize = primaryFontSize, labelAlign = "center", labelColor = { default={ 89/255, 97/255, 86/255 }, over={ 160/255, 177/255, 86/255 } } }) -- add to the scrollView levelSelectGroup:insert(buttons[id])

The performance is bad on my iPhone 6. All my current data has 100 buttons (or less) per scrollview, only one scrollview in view at a time and the performance is really sluggish, it’s visibly lagging, the rendering looks like it’s stuttering. Any ideas? I verified that I don’t have button events firing during scroll or anything like that.

#5

Hi @SecretAsianMan,

May I ask why you’re not using a tableView widget for this? Considering that it scrolls only vertically, that seems like a better option, and tableView automatically “culls” offscreen objects (removes them when they’re off screen and puts them back on when they’re about to return into the view).

Brent

#6

@Brent,

I have a vertical grid layout; from what I can discern from the docs it looks like the tableview is limited to vertical lists only?

If the button controls are too heavyweight to have ~100 of them in a list, would it save much to attach events to a primitive like a rect?

#7

You can certainly create a vertical grid with a Tableview; I have. But you will have to roll your own. See discussion from last week here: https://forums.coronalabs.com/topic/57299-dual-cell-in-table-view/

One downside is that, in my experience, Tableview’s perceived user performance is not as crisp or smooth as Scrollview’s.

#8

I see, interesting. I get it, you just portion up rows and slam them in yourself.

I’m surprised to hear you say that scrollView’s performance is better. Even when I drop to 20 buttons it’s pretty laggy. I think I may end up redesigning these menus to minimize scrolling… Will have to keep this in mind when I’m deciding on platforms for future projects.

#9

My scrollviews have about 30-100 items in them – mostly text but some large images and graphics – and they’re fine on my iPhone 6 Plus using 2015.2638. More precisely, I just checked and they may not be quite as fluid as a native app, but you would have to look hard to tell the difference. 

Because you didn’t post what build you’re using or other details, you may not get the help you’re looking for. You also didn’t say what the performance of Corona’s sample Scrollview project looks like on your device. Some video may be helpful too.

#10

Thanks. I just upgraded to 2015.2646 and it’s noticeably better, but still much worse than the native controls. It feels *OK* on device, but worse in the simulator.

If I can find some spare time I’ll see if I can put together a min-repro.

#11

Alright, I loaded up the Widget Demo sample and changed the background element to be tall enough to actually scroll (changed the height from 512 to 5120) and on my iPhone 6 it is not very good. Fast swipes and such are totally missed, it’s really hard to scroll any distance at a time. That said, even though the sample feels bad to use, it is rendering smoothly.

As per my own app, I have a scrollview with ~100 button widgets inside of it. The scrollview is defined like this:

levelSelectGroup = widget.newScrollView({ left = 0, top = titleBarHeight, width = display.contentWidth, height = display.contentHeight - titleBarHeight, scrollWidth = display.contentWidth, horizontalScrollDisabled = true, hideBackground = true })

and I have a loop that generates button widgets and inserts them like this:

buttons[id] = widget.newButton({ label = tostring( puzzleData.index ), id = id, left = xOffset, top = yOffset, onEvent = handleLevelSelect, emboss = false, width = buttonWidth, height = levelButtonHeight, font = native.systemFont, fontSize = primaryFontSize, labelAlign = "center", labelColor = { default={ 89/255, 97/255, 86/255 }, over={ 160/255, 177/255, 86/255 } } }) -- add to the scrollView levelSelectGroup:insert(buttons[id])

The performance is bad on my iPhone 6. All my current data has 100 buttons (or less) per scrollview, only one scrollview in view at a time and the performance is really sluggish, it’s visibly lagging, the rendering looks like it’s stuttering. Any ideas? I verified that I don’t have button events firing during scroll or anything like that.

#12

Hi @SecretAsianMan,

May I ask why you’re not using a tableView widget for this? Considering that it scrolls only vertically, that seems like a better option, and tableView automatically “culls” offscreen objects (removes them when they’re off screen and puts them back on when they’re about to return into the view).

Brent

#13

@Brent,

I have a vertical grid layout; from what I can discern from the docs it looks like the tableview is limited to vertical lists only?

If the button controls are too heavyweight to have ~100 of them in a list, would it save much to attach events to a primitive like a rect?

#14

You can certainly create a vertical grid with a Tableview; I have. But you will have to roll your own. See discussion from last week here: https://forums.coronalabs.com/topic/57299-dual-cell-in-table-view/

One downside is that, in my experience, Tableview’s perceived user performance is not as crisp or smooth as Scrollview’s.

#15

I see, interesting. I get it, you just portion up rows and slam them in yourself.

I’m surprised to hear you say that scrollView’s performance is better. Even when I drop to 20 buttons it’s pretty laggy. I think I may end up redesigning these menus to minimize scrolling… Will have to keep this in mind when I’m deciding on platforms for future projects.