5
votes

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! :)

1
I think it's best to find at runtime what's the maximum texture size and after that you can partition your image as needed. Also you can scale it before, if your screen has lower density, for example...Display Name

1 Answers

3
votes

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.