Context: 3rd gen iPad (IOS 8.3) using latest juce build 3.2.0 (7/22 update)
I have a viewport that I display several rows of data in. Each row consists of a couple of buttons and 3 or 4 labels with text. Nothing fancy.
On OSX, this works beautifully and when I move up and down using either the scroll bar or touch pad the motion is very smooth and fluid.
On IOS, I can't use swipe (it's not supported currently, right?) so I use the scrollbar to move up and down in the view. On IOS, the movement lags significantly resulting in jumpy-looking display. While dragging the CPU is pegged at 100% and I can see paint() is only being called 3 or 4 times per second at most. (On OSX, the paint() calls / sec is much faster and CPU is pretty bored .)
I've tried enabling the opengl renderer in case that isn't the default (no idea)- didn't help. Same results.
Scrolling of this nature should be trivial for this device and, in fact, is so for tons of other apps that do pretty much exactly the same thing with MUCH larger viewports (mail with 2500 mails in my inbox, contacts, etc.).
Is there a known perf issue with Juce / scrolling on IOS? I'm super surprised to be having this issue.
I had this very same issue. So I have gone back and redone my main UI structure using UIKit in Objective-C/C++ and Swift. A bit of a learning curve but worth it. I made a test app with a scrolling ListBox on its own which worked fine. But as soon as any audio processing is going on, scrolling became slow and jittery. A simple test with a UITableView and my JUCE app in a UIView inside a UIViewController gave me the smooth behaviour I was hoping for.
Interestingly, it's mostly a non-issue on the new iPod I just purchased, but it's quite noticeable on the iPad gen 3. I haven't looked at how much CPU gain there is between those generations of devices, but assume there is just more under the hood CPU-wise in the newer device (given it's CPU that's pegged in the perf test where the slowdown is happening).
Adamski, I understand your approach but I'd rather not chase this that way given my primary reason for using JUCE is cross-platform portability (IOS, Anroid, OSX, Windows).
I'm hoping the "Speed up lists on mobile" to do accomodates active buttons, etc. in the "list" vs. just display data that cannot be interacted with beyond scrolling it.
Jules, I also hacked JUCE to get it to give my app a callback for touchesBegn/Moved/Ended so I could roll-my-own swipe feature for scrolling viewports. Not my preference but it works ok until you fine folks add swipe support formally. Any sort of ETA for either "swipe" or "speeding up lists on mobile"? Btw, I searched pretty hard for some evidence that this was on a to-do-list somewhere and didn't find it. Is that list public and I'm just not finding it?
Thanks for JUCE and the Introjucer. I am using both a ton. Love the overall model, the C++ness and the forum. :)
This post might interest you if you want to see someone else's implementation of a viewport and listbox that scrolls with a mouse drag. I haven't tried it yet, but it seems to work well from the comments. As far as performance goes, I guess we'll just have to wait.
Believe me I wanted to keep in pure JUCE as much as possible and not have to delve out it into platform specific code. But performance and usability concerns have led me in this direction. Its a little fiddly getting things hooked up together but for my needs at least I think it is well worth it.
In my case I'm also using Couchbase Lite as my data store which is also platform specific, so my UI can hook into the database directly and then send the data to my C++ classes when needed.
