This page is incomplete, and may be incorrect. Read at your own risk.


Argo is based around several core components. These components form the foundation on which you will build your application.

Below you will find high level explanations of what each component does, and how they fit together to render an HVR. This document assumes you are using the standard Argo integration, using HvrView and/or HvrTextureView. If you are familiar with 3d rendering, and are wanting to use HVR content inside a rendering engine such as LibGDX or Rajawali, you’ll want to check out the section on advanced rendering.

Important Terms

  • Rendering thread - this is a thread that is detached from the main Android UI thread, and is where most of the interactions with Hvr* objects should occur.

HvrView and HvrTextureView

The HvrView and HvrTextureView are Android View objects. At the most simple level, these Views provide a place for you to render HVR content in your application. Each HvrView/HvrTextureView requires that you provide it with an HvrPlayer, which will control what is rendered into that View.

In short: The HvrView/HvrTextureView provides the canvas that an HvrPlayer will draw things onto.

What’s the difference between an HvrView and an HvrTextureView?

The difference between an HvrView and an HvrTextureView is subtle but important.

An HvrView is a GLSurfaceView, which punches a hole through your screen to perform rendering. If you imagine that all your UI is sitting above an underlying screen, the HvrView punches a hole through your UI, to this screen, and then renders onto this screen. An HvrView will be slightly faster to render than an HvrTextureView, but is unable to be animated or transformed in the way you would expect a traditional Android View to be animated or transformed.

An HvrTextureView is a TextureView, which renders content in a manner that is more consistent with other Android Views. The HvrTextureView renders content into a SurfaceTexture, and then displays this SurfaceTexture inside of a View, which is part of the standard Android View hierarchy. This allows an HvrTextureView to be treated much more like a traditional Android View, and animated or transformed as your application requires.

Unless you are extremely concerned with performance, or are creating a full-screen/immersive mode application, we recommend that you use an HvrTextureView, as it will act in way that is similar to a standard Android View object.


An HvrPlayer owns an HvrRenderer, and is a little bit like an Activity or Fragment - it has its own lifecycle, and is the root that all other functionality grows out of. HvrPlayer is an abstract class that requires the onRender method to be implemented by any implementations. The onRender method is where an implementation is expected to call the render method of the HvrRenderer that the HvrPlayer owns, and perform any additional rendering.

The HvrPlayer also provides a point from which you can post events to the rendering thread and attach HvrBehaviours.


An HvrRenderer is the binding between an HvrPlayer and an HvrActor. An HvrRenderer creates and renders HvrActors on request.


An HvrActor represents the data from an HVR(S) file. When an HvrActor is attached to an HvrRenderer, calling HvrRenderer.render will cause that HvrActor to be rendered to the screen.


An HvrBehaviour is like a small extension of HvrPlayer.