Oomph does an awesome job of taking the complexity out of designing killer content for your apps & publications. However, because it seems so simple and easy to use, it's very easy to get carried away and overdo your content - putting in too many bells and whistles. Content such as this may cause page loads to be slow, or animation timings to be off, and - at worst - use all the memory on the iPad causing iOS to kill the app (and possibly others running).
This page gives you a technical overview of what makes a page slow to load and how the rendering of page content works on Oomph.
Nine simple tips to create faster content
Below is a collection of tips & tricks that can help you avoid common memory & performance related issues as well as reduce the size of your content.
1. Limit your layers
Avoid using layers that contain mostly transparency with a minor content element. Alternatively, if you must use full screen animated layers, consider only using a small number of layers - less than five is a good number.
Also, if you're creating animated elements on top of long pages, keep the transparent layers only as large as the first page (i.e. one screen full). Using long transparent layers causes the iPad to alpha blend content as you scroll, resulting in both more memory usage and slower scrolling speed.
2. Objects instead of layers
If you are animating a layer with artwork in only part of the screen consider using object instead. Object hotspots can be animated in the same way as layers animations. Create an object hotspot at the same size as your artwork and export the object separately. See the Objects page to learn how to create Objects and the Animated Widget page to learn how to animate hotspots.
3. The flatter, the faster
Avoid exporting pages and slides with transparency effects e.g. drop shadows, bevels, inner shadows, opacity, blending modes, glows, gradients and feathers.
A good best practice is to create your designs with whichever effects you desire and then once you are happy with the look, export your artwork out as png files and import them back into your document. Using this method allows you to use any effect at your disposal without losing performance.
Leave all your copy in a vector format, it is best to have your text as crisp as possible for legibility. Again, try not to apply effects to the text for best results
4. HTML Pages
5. Flipbooks with Retina Images
Flipbooks with retina quality images are also known to cause problems on iPad 3. Consider downscaling the images or using fewer images.
6. IPS with Retina Images
IPSes can use considerable resources if the slides are high resolution images. Remember that even on a non-retina device the full-resolution image must be loaded before being down-scaled to fit the dimensions of the IPS region, and that up to three slide are cached for smooth scrolling performance.
7. Consider Restructuring Content
If you choose to author content that causes heavy memory usage, consider restructuring your content so that these pages are not located adjacent to one another. This will allow the iPad to avoid caching large pages in memory and improve the performance of your content.
8. Resize and trim your video
If you are including video into your content, make sure that the longest edge is no more than 1024 pixels and if you are using your video in an In Page Video (IPV) consider resizing the video to match the size of your hotspots.
If you need to use the same video in multiple sections, share the the video from the one section by using the following hotspot: V[SECTION NAME] e.g. VFeature-1
9. Always Test on Device!
Always test content on device, remember the iPad is not a desktop computer, it only has a limited system resources. If your content is reasonably similar, consider testing an indicative sample page on device before building all your content using that template. This can help flesh out problems early before you've committed to producing all your content.
If you have content causing problems, try previewing content sections individually to see which ones cause the problems.
Be sure to test on a range of devices - the original iPad1 has only one quarter of the memory capacity of the new iPad.
Page Loading & Caching
To improve the speed of loading pages, Oomph preemptively renders and caches pages adjacent to the page being viewed. For a normal page in the middle of your content, Oomph will cache:
The current page being viewed.
The page above the current page in the section (if you're in the middle of a section).
The page below the current page in the section (if you're in the middle of a section).
The page to the left of the current page (if you're not in the first section).
The page to the right of the current page (if you're not in the last section).
You can see that this could cache up to 5 pages (and their constituent layers) in memory at any one time.
A similar system is used for in-page slideshows (i.e. IPS and VIPS). Where the slideshow is small the impact is minimal, but if they are approaching the full size of the screen, or if the slides are retina scaled images the memory requirement can be substantial. The visible slide plus the two adjacent slides are cached i.e.:
The current visible slide.
The slide to the left for IPS, or above for VIPS.
The slide to the right for IPS, or above for VIPS.
The same applies to full-screen slideshows, but these are only loaded when the user taps to open the slideshow.
As part of the rendering process, content is rasterised from its original format (PDF/HTML, etc.) into an image, the image is then rendered to screen. Some of these rasterised images are then also cached in memory (as per the above). Keeping too many images of these layers in memory can cause problems such as the iPad feeling laggy, slow scrolling or even crashes. To understand why, let's look at how the iPad renders content to screen.
To render a page to screen, each of its layers is composited on top of one another (taking into account any alpha channel), then rasterised to screen. If pages contain animated layers with alpha channels, the final composite image cannot be cached, it must be composited live each time the animation runs.
A retina iPad has a resolution of 2048×1536 pixels, which, doing the maths (see below), leads us to a rasterised using up 12 MB of memory. If you use transparent animated layers, each layer is also kept, so this is 12 MB per layer. Doing some quick maths, if you had 1 base layer & 9 transparent animated layers in a page (so 10 in total), that's 120 MB of memory needed for just one page. And to take this to the extreme, if you used this technique in adjacent pages, you could end up with up to 600 MB being used at any one time. This may sound like an extreme example, but we have seen live content that uses over 20 transparent animated layers.
It is also important to realise that image based content files (JPGs and PNGs) are decoded to their full native resolution before they can be drawn, regardless of the screen resolution. For example, a retina-sized JPG file at 2048×1536 will require 12MB of memory even when displayed on a non-retina device at 1024×768 resolution. Due to this we advise to avoid using retina images where possible. See tips and tricks for more information.
So even if you don't follow the math completely, the summary is that it's very easy to build content that can cause problems when running on device. And while Oomph can hide a lot of the complexity, at some point you run up against hardware limitations.
Post is closed for comments.