Android scrolling menus


#1

Hi,

I need the user to select values in my app, and am therefore trying to reproduce the standard Android menus. For that, I have created a viewport containing a certain number of Labels. When user starts a drag operation on the component, I change the viewport Y position. This works perfectly on my desktop, but when I deploy the app on an actual phone, the scrolling is very hectic and laggy. I guess it must be because the process is too heavy for these devices processors.

What would you recommend to achieve the same result, but in a lighter way? I don’t really need the “inertia” feature, where the list keeps scrolling when you lift your finger, though that would be a plus.

Thanks for any help on the matter.

Mariano


#2

It does actually the same when you allow the display of scroll bars and scroll through that. Seems the refresh takes time.


#3

Two things would be needed to make it really smooth:

  • making the Viewport class smart enough to cache its content as a bitmap for re-use when scrolling
  • an openGL renderer for android

Both on my to-do-list!


#4

Yes, I was just thinking that making a bitmap out of the different labels would solve the problem. Is it something I could do while waiting for your implementation, using some existing classes?


#5

Sure, you could probably do quite a bit with just Component::setBufferedToImage()


#6

great! I’ll investigate that. Thanks


#7

I tried that, but didn’t see any improvement. I then did my own implementation, creating a custom image out of the texts when loading the menu, then showing part of the image in the paint() method using drawImage() with a specific vertical offset. That offset is incremented/decremented in the mouseDrag() method, followed by a repaint().

Unfortunately, this remains as slow as the rest, which is surprising since scrolling an image should be fast. Is it maybe because the paint method is called at a lower frequency on Android? Because I drag and then after 0.5 to 1 second I see the list scroll to that position.

Or is it the drawImage() method that is slow?

I am ready to change the selection of items into some kind of scrolling box, showing one item at a time, so as to solve this problem, but I’d have liked to stick to a more standard way of presenting choices, and also to understand what is preventing this scrolling to move smoothly. So any further help/info would be greatly appreciated.

Thanks.

Mariano


#8

Could just be that getting the pixels to the device’s graphics hardware is too slow - that’s why I’d like to get an openGL renderer for android (and iOS). I’m actively looking for someone who might want to have a go at that task!


#9

Oh, I understand. You need to pass the pixels back to the Java app through a JNI function. I didn’t realize that.

I think rather than trying to optimize the graphics rendering, it may be better to allow for the Java app to use the Juce lib through its lifecycle. I mean, to allow us to call custom JNI functions within the Juce lib. In that way, we can use the Java part for UI, and the Juce lib for the rest.

With that approach, I would have a light UI in Java. When user clicks on a field, I would call a method in my Juce lib to retrieve the array of options, display it in Java, and then return the selected value to the C++ lib.

I had made a Java UI that way for a C++ app to make it portable, at the time when I hadn’t yet heard about Juce;-)


#10

Sorry to dig up an old thread, but just want to point out that even with the OpenGL rendering there is still an issue with laggy dragging and scrolling.

From some testing I did recently I came to the conclusion that, when the Android OS is doing processer heavy work it limits the number of touch events sent from the UI, and so the JUCE code only receives limited number of touch events which results in jittery / laggy performance. So what is needed is to interpolate the events, i.e. generate extra MouseEvents in between the recieved touch events if they are are over a given distance apart. 

This is something I want to look at soon, there's a couple of older threads on the subject:

http://www.juce.com/forum/topic/tips-responsive-gui

http://www.juce.com/forum/topic/what-about-componentdraggerlistener