Drawing large background image with libgdx - best practices?

Question

I am trying to write a libgdx livewallpaper (OpenGL ES 2.0) which will display a unique background image (non splittable into sprites).

I want to target tablets, so I need to somehow be able to display at least 1280x800 background image on top of which a lot more action will also happen, so I need it to render as fast as possible.

Now I have only basic knowledge both about libgdx and about opengl es, so I do not know what is the best way to approach this.

By googling I found some options:

• split texture into smaller textures. It seems like GL_MAX_TEXTURE_SIZE on most devices is at least 1024x1024, but I do not want to hit max, so maybe I can use 512x512, but wouldn't that mean drawing a lot of tiles, rebinding many textures on every frame => low performance?
• libgdx has GraphicsTileMaps which seems to be the tool to automate drawing tiles. But it also has support for many features (mapping info to tiles) that I do not need, maybe it would be better to use splitting by hand?

Again, the main point here is performance for me - because drawing background is expected to be the most basic thing, more animation will be on top of it!

And with tablet screen growing in size I expect soon I'll need to be able to comfortably render even bigger image sizes :)

Any advice is greatly appreciated! :)

Answer 1

Many tablets (and some celphones) support 2048 textures. Drawing it in one piece will be the fastest option. If you still need to be 100% sure, you can divide your background into 2 pieces whenever GL_MAX_TEXTURE happens to be smaller (640x400).

'Future' tables will surely support bigger textures, so don't worry so much about it.

For the actual drawing just create a libgdx mesh which uses VBOs whenever possible! ;)

Two things you dindn't mention will be very important to the performance. The texture filter (GL_NEAREST is the ugliest if you don't do a pixel perfect mapping, but the fastest), and the texture format (RGBA_8888 would be the best and slowest, you can downgrade it until it suits your needs - At least you can remove alpha, can't you?).

You can also research on compressed formats which will reduce the fillrate considerably!

I suggest you start coding something, and then tune the performance up. This particular problem you have is not that hard to optimize later.