"Infinite" scroll photo album / activity feed performance

I'm looking into the viability of switching from Coherent UI (essentially a webkit browser) to uGUI on iOS/Android. My app is very UI & image heavy (more like facebook than a normal 3D game) so I wanted to prepare a representative test. I wanted to check the test would be "fair" so I'm looking for feedback on best practices in this scenario. Hopefully others will find the info useful when implementing something like this for real.

The most intensive thing I thought of mocking up quickly is taking a directory of n hi-res thumbnails (think retina) in a 2 or 3 wide grid and scrolling through. This puts a lot of pressure on other elements of Unity3d outside uGUI (loading and encoding textures) but for my purposes thats part of what I'm testing and it can also be circumvented by loading up front if I just want uGUI rendering benchmarks.

It seems other people have struggled encoding images to textures on mobile (which is odd when it happens in a negligible amount of time in the browser in hardware accelerated mode). This thread has the most useful info on that process http://answers.unity3d.com/questions/511268/texture2dloadimage-too-slow-for-use-ios.html#

Using .texture [instead of LoadImage] cuts the load time for me down from 250ms to 50ms, .textureNonReadable cuts this down further to under 20ms.

I'm also tempted to store the thumbnails as bytes in ARGB or a more compressed format, and pretend we have the full res jpeg saved somewhere if we need the quality later, or if it needs to be shared to the web.

This article suggests that www.texture loads arent very memory friendly, and a way to manage that http://dunenkoff.wordpress.com/2014/03/30/unity3d-loading-external-images/

All together this makes me think the system should read the folder contents into a list and generate some uGUI thumbnail sprites in a scrollable area, loading in those files that are visible.

When the user scrolls the system should assign a number of www loaders that begin loading via coroutine if an "empty" thumbnail sprite is close to the leading edge of the scrollable area, until all the thumbnails are loaded or the frame time is over a time threshold (like 14ms). At least one image should be loaded so we are making progress each frame.

On the trailing edge of the scrollable area, the thumbnail sprite textures are destroyed and the thumbnail objects themselves added to the leading edge ready to come into view (thereby limiting the number of objects to the number required to fill the view + a few rows either side for loading into).

Does this sound like a reasonable implementation to test against Coherent UI? Is it over-engineered (in that Unity3D would handle some of the optimisations automatically)? Is there any other low-hanging-fruit I'm missing in terms of optimisation?

 

Since I'm kind of in the same boat, why are you considering a switch from Coherent UI to uGUI? One reason I can think of is that Coherent UI has a mobile footprint of about 50 MB, is that it?

 

A few reasons:

- We are trying to cut down on native plugins as much as possible as our old Android build process got quite convoluted (various things extending UnityPlayer, lots of bridges to native code)
- Slower pace of iteration when developing (the desktop browser isnt equivalent with the mobile browser in terms of features or layout, so full builds were required to test UI once we hit a certain stage where things started looking different between desktop, iOS and Android)
- Coherent Labs Licensing changes and update schedule. Although they were always very responsive, I dont feel that 1.x really got to a stage I was fully happy with before the 2.0 release, and now the licensing is more expensive.
- More variation in Android browser versions than anticipated, set to increase as Chrome is added to the Android OS level browsers in 4.4 .
- We used Angular JS, so there was need to write and maintain code that bridged the UI data between Unity and CoherentUI. A lot of bugs came about purely due to maintaining & debugging this code (which is mostly my fault).
- We hadn't focused deeply on optimisation, but we had issues with lag, and our core app was always going to be resource-hungry. A Unity solution might allow us to balance resources better - the remnants of NGUI we had always ran a bit better.

That said, we will definitely miss the speed of adding features that having access to every web library and browser feature can bring (adding map view in a few hours, or vector graphic animations etc).

 

Wow. Almost every point you mention is what I previously considered to be a benefit, but turns out to be a downside. Seems like it's not a case of design once, deploy anywhere.

I have considered a combination of CoherentUI with several MV* libraries, but I don't really like the Javascript ecosystem after all. I'm now looking forward to the integration of NoesisGUI with uFrame for a C# and XAML-based MVVM framework.

That said it's indeed worth checking out a workflow with the new built-in Unity GUI and no other dependencies.

 

I think in a lot of cases those benefits are real (say with a desktop-targeted game with simple UI made up of flexboxes). Unfortunately in our case we are very UI heavy, mobile focused, and making Unity do things its not good at which means plugins and native code in the build process.

I learned angularJS for the project and found it pretty pleasant to work with. Have you looked at strangeIOC? I only just learned it existed the other night. It looks a little overly complex but I'm not aware of many alternatives within Unity3d.

 

Yes, I actually tried strangeIOC a while ago. I felt it involves a lot of bookkeeping, but maybe it gets better with experience. I noticed the developer put the project on hold and there appear to be some issues. I'd rather use something that's under active development and/or is mature. So that's why I moved on to uFrame. Although it's not completely mature yet, it's at least being worked on. And it has this nifty pseudo-UML-ish diagram that generates the boilerplate and is useful for a visual overview.

That said, Ember/AngularJS's type binding is really something. Besides the ease of use, no need for dependency tracking, lack of boilerplate, there is a benchmark that put dirty checking against events and curiously dirty checking wins by an order of magnitude in the latest version Chrome. I haven't verified the design of the test itself though.

But now we are going off-topic. Have you designed a test for the images scrollview? I'd like to see how it fares in NoesisGUI.

 

Unfortunately I haven't had time to sit down and build a proper implementation yet (I only just realised theres a built in grid layout while listening to some Unite videos). This person posted that they would be expanding this repo to include pooling/reuse of objects etc. so they might get there before me https://github.com/alhaddado/unity-scrolly .

uFrame looks really interesting - it looks like it maintains the separation I need for UI/logic and working in teams on a complex UI - although I'm curious how the generated side of things stands up over the course of a long-running project with lots of changes and refactoring.