1
\$\begingroup\$

I've been trying to come up with a good solution for preloading textures asynchronously, but in Android with OpenGL ES you cannot create a texture out of context.

Would the proper solution be to load up a ByteBuffer with data from my png image, then when I'm back on the render thread call glTexImage2D? What I don't understand is whether or not OpenGL will actually copy the buffer into it's own location, or directly access mine. The latter approach would be ideal.

Could anyone give me clarification?

\$\endgroup\$
2
  • \$\begingroup\$ Why exactly you want to load textures on another thread? It is so much simpler to let this on the main context one, though you may have a good reason to do it. \$\endgroup\$
    – Alexandre Desbiens
    Commented Jul 22, 2014 at 17:54
  • 1
    \$\begingroup\$ Loading textures -- or anything large -- from disk is unpredictable (often slow). It's generally better to defer such tasks to a worker thread so as not to stall the main thread, interrupting UI interaction. \$\endgroup\$
    – user1430
    Commented Jul 22, 2014 at 18:18

1 Answer 1

Reset to default
1
\$\begingroup\$

Would the proper solution be to load up a ByteBuffer with data from my png image, then when I'm back on the render thread call glTexImage2D? What I don't understand is whether or not OpenGL will actually copy the buffer into it's own location, or directly access mine. The latter approach would be ideal.

This is basically what you want to do. Load the texture data from a worker thread, and once the load is complete construct the OpenGL texture resource (from that data) on the main/render thread.

Once you call glTexImage2D, you don't need to keep your copy of the texture data in-memory any longer (you can delete it) unless you need it for some other purpose. OpenGL will copy the data it needs elsewhere.

\$\endgroup\$
5
  • \$\begingroup\$ Ah darn I wish OpenGL just pointed to my buffer so I could keep it around. I guess it's fairly simple just to load it asynchronously and pop it into OpenGL and keep it there. Thanks \$\endgroup\$
    – Josplode
    Commented Jul 22, 2014 at 19:35
  • \$\begingroup\$ "Just pointing to the buffer" would be pretty difficult from a hardware design perspective, unfortunately, since the GPU is a discrete unit of hardware. \$\endgroup\$
    – user1430
    Commented Jul 22, 2014 at 20:06
  • \$\begingroup\$ Well for a PC, but I had the idea that Android phones just use regular RAM for video memory. I could be mistaken \$\endgroup\$
    – Josplode
    Commented Jul 22, 2014 at 20:12
  • \$\begingroup\$ Wouldn't matter -- you're talking about a core OpenGL API which would want to maintain cross-platform abstractions. Anything that would do something like what you are describing (and it might be possible, just not via glTexImage2D) would be an extension. You should perhaps browse the extensions registry, you may find something useful. \$\endgroup\$
    – user1430
    Commented Jul 22, 2014 at 20:25
  • \$\begingroup\$ cf. "texture swizzling" and related topics. The format of the image loaded from disk may be suboptimal for access by the hardware, so being able to rewrite the texture can provide significant performance improvements. So not only would avoiding the copy be a restrictive API design for non-UMA systems, it could also cause a performance hit. \$\endgroup\$
    – fadden
    Commented Jul 28, 2014 at 14:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .