Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Texture size limitation on OpenGL ES 1.0 (Android)
1,233 views
Skip to first unread message
Miha
Jan 31, 2012, 8:13:12 AM1/31/12
to
Hi!
I'm developing an Android application, which displays a remote
framebuffer (think VNC) using OpenGL ES 1.0. Since remote framebuffer
can be quite large and I'm using a native library (C++) to do the
framebuffer update heavy lifting, I'm transferring framebuffer data to
Java using ByteBuffer (JNI NewDirectByteBuffer). I am then applying
this byte buffer as a texture to a simple plane I construct (width=1,
height=(pixelwidth/pixelheight)).
I was doing all of my testing on Samsung Galaxy S2 and Galaxy Tab 10.1
where texture size limitation was not apparent (2^n x 2^m texture size
was not requirement). But when testing on Galaxy Nexus (with Android
4.0 ICS), this limitation arose and I modified my code to always
create framebuffer image of size 2^n x 2^m and apply it to my plane
using modified UV coordinates.
Furthermore, texture sizes beyond 2048x2048 pixels don't show up on
Galaxy Nexus (ICS), whereas I can use them without problems in Galaxy
S2 (running Android 2.3).
While debugging, I queried maximum texture size using:
gl.glGetIntegerv(GL10.GL_MAX_TEXTURE_SIZE, intBuf);
On SGS2 I get 4096 and on Galaxy Nexus (Android 4.0) I get 2048
pixels. Also, when applying the texture on Galaxy Nexus, the result of
glTexImage2D operation is 1281 (GL_INVALID_VALUE) and I only see a
white plane without mapped texture.
So, I'm hitting a limitation here. The catch is that I can't scale the
texture down, since I'm zooming into the plane so that the end user
sees the pixels at 1:1. Also, my requirement is that I need to support
multiple monitors, so the resolution could grow to 3*2560 = 7680pixels
wide.
The problem is, that OpenGL was the only approach I could use to
display big bitmaps on Android, but I seem to be hitting a hard wall
here.
Does anybody have a suggestion on how to move forward?
Thanks,
Miha.
ps: I should add that I am newbie with regards to OpenGL and that I
might have used a wrong terminology above.
I'm developing an Android application, which displays a remote
framebuffer (think VNC) using OpenGL ES 1.0. Since remote framebuffer
can be quite large and I'm using a native library (C++) to do the
framebuffer update heavy lifting, I'm transferring framebuffer data to
Java using ByteBuffer (JNI NewDirectByteBuffer). I am then applying
this byte buffer as a texture to a simple plane I construct (width=1,
height=(pixelwidth/pixelheight)).
I was doing all of my testing on Samsung Galaxy S2 and Galaxy Tab 10.1
where texture size limitation was not apparent (2^n x 2^m texture size
was not requirement). But when testing on Galaxy Nexus (with Android
4.0 ICS), this limitation arose and I modified my code to always
create framebuffer image of size 2^n x 2^m and apply it to my plane
using modified UV coordinates.
Furthermore, texture sizes beyond 2048x2048 pixels don't show up on
Galaxy Nexus (ICS), whereas I can use them without problems in Galaxy
S2 (running Android 2.3).
While debugging, I queried maximum texture size using:
gl.glGetIntegerv(GL10.GL_MAX_TEXTURE_SIZE, intBuf);
On SGS2 I get 4096 and on Galaxy Nexus (Android 4.0) I get 2048
pixels. Also, when applying the texture on Galaxy Nexus, the result of
glTexImage2D operation is 1281 (GL_INVALID_VALUE) and I only see a
white plane without mapped texture.
So, I'm hitting a limitation here. The catch is that I can't scale the
texture down, since I'm zooming into the plane so that the end user
sees the pixels at 1:1. Also, my requirement is that I need to support
multiple monitors, so the resolution could grow to 3*2560 = 7680pixels
wide.
The problem is, that OpenGL was the only approach I could use to
display big bitmaps on Android, but I seem to be hitting a hard wall
here.
Does anybody have a suggestion on how to move forward?
Thanks,
Miha.
ps: I should add that I am newbie with regards to OpenGL and that I
might have used a wrong terminology above.
Wolfgang.Draxinger
Jan 31, 2012, 9:26:32 AM1/31/12
to
On Tue, 31 Jan 2012 05:13:12 -0800 (PST)
Miha <miha.v...@gmail.com> wrote:
> Hi!
>
> I'm developing an Android application, which displays a remote
> framebuffer (think VNC) using OpenGL ES 1.0. Since remote framebuffer
> can be quite large and I'm using a native library (C++) to do the
> framebuffer update heavy lifting, I'm transferring framebuffer data to
> Java using ByteBuffer (JNI NewDirectByteBuffer). I am then applying
> this byte buffer as a texture to a simple plane I construct (width=1,
> height=(pixelwidth/pixelheight)).
Pro-Tipp for remote framebuffer: Only transmit difference pictures and
Miha <miha.v...@gmail.com> wrote:
> Hi!
>
> I'm developing an Android application, which displays a remote
> framebuffer (think VNC) using OpenGL ES 1.0. Since remote framebuffer
> can be quite large and I'm using a native library (C++) to do the
> framebuffer update heavy lifting, I'm transferring framebuffer data to
> Java using ByteBuffer (JNI NewDirectByteBuffer). I am then applying
> this byte buffer as a texture to a simple plane I construct (width=1,
> height=(pixelwidth/pixelheight)).
limit them to the area of change.
> While debugging, I queried maximum texture size using:
> gl.glGetIntegerv(GL10.GL_MAX_TEXTURE_SIZE, intBuf);
> On SGS2 I get 4096 and on Galaxy Nexus (Android 4.0) I get 2048
> pixels. Also, when applying the texture on Galaxy Nexus, the result of
> glTexImage2D operation is 1281 (GL_INVALID_VALUE) and I only see a
> white plane without mapped texture.
allowed value for either width and height. However it's still possible
for a texture of large dimensions, but within the theoretical limits to
exceed available OpenGL memory.
> The problem is, that OpenGL was the only approach I could use to
> display big bitmaps on Android, but I seem to be hitting a hard wall
> here.
>
> Does anybody have a suggestion on how to move forward?
Wolfgang
Miha
Jan 31, 2012, 2:54:49 PM1/31/12
to
Hi Wolfgang!
On Jan 31, 3:26 pm, "Wolfgang.Draxinger"
> > Does anybody have a suggestion on how to move forward?
> Use multiple textures and tile your images.
I thought about that, although it is quite a stretch to implement
that. I would need to tile the planes in sort of a grid and then apply
textures to each of them. That would be the easy part. I'd have to
modify the library so that I would have access to "tile framebuffers"
as it does not make sense to copy the tile data for each frame update.
So, basically, what you're saying in other words is, that even though
I have texture size limitation X, I can use (for instance) 9 textures,
each with this limitation?
Thanks,
Miha.
On Jan 31, 3:26 pm, "Wolfgang.Draxinger"
<Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
> Pro-Tipp for remote framebuffer: Only transmit difference pictures and
> limit them to the area of change.
Sure, thanks. The library is already doing this (QtVNC kind of stuff).
> Pro-Tipp for remote framebuffer: Only transmit difference pictures and
> limit them to the area of change.
> > Does anybody have a suggestion on how to move forward?
> Use multiple textures and tile your images.
that. I would need to tile the planes in sort of a grid and then apply
textures to each of them. That would be the easy part. I'd have to
modify the library so that I would have access to "tile framebuffers"
as it does not make sense to copy the tile data for each frame update.
So, basically, what you're saying in other words is, that even though
I have texture size limitation X, I can use (for instance) 9 textures,
each with this limitation?
Thanks,
Miha.
Miha
Feb 1, 2012, 12:04:16 PM2/1/12
to
On Jan 31, 8:54 pm, Miha <miha.valen...@gmail.com> wrote:
> So, basically, what you're saying in other words is, that even though
> I have texture size limitation X, I can use (for instance) 9 textures,
> each with this limitation?
I did some testing. Indeed, the textures show up, but performance is
> So, basically, what you're saying in other words is, that even though
> I have texture size limitation X, I can use (for instance) 9 textures,
> each with this limitation?
very poor. Could it be that when I load more textures, HW acceleration
gets disabled and it is being processed with CPU or something along
those lines?
Thanks,
Miha.
Wolfgang Draxinger
Feb 1, 2012, 5:10:29 PM2/1/12
to
using glTexSubImage2D for image updates. glTexImage2D usually goes
through a full texture object initialization.
Wolfgang
Wolfgang Draxinger
Feb 1, 2012, 5:12:36 PM2/1/12
to
On Tue, 31 Jan 2012 11:54:49 -0800 (PST)
Miha <miha.v...@gmail.com> wrote:
> I thought about that, although it is quite a stretch to implement
> that. I would need to tile the planes in sort of a grid and then apply
> textures to each of them. That would be the easy part. I'd have to
> modify the library so that I would have access to "tile framebuffers"
> as it does not make sense to copy the tile data for each frame update.
You don't have to segment your input data. OpenGL can do this for you.
Miha <miha.v...@gmail.com> wrote:
> I thought about that, although it is quite a stretch to implement
> that. I would need to tile the planes in sort of a grid and then apply
> textures to each of them. That would be the easy part. I'd have to
> modify the library so that I would have access to "tile framebuffers"
> as it does not make sense to copy the tile data for each frame update.
glPixelStorei allows you to control how OpenGL reads the images from
the buffer you give to it.
See this chapter of the Red Book, especially figure 8-9 is of interest
for your:
http://glprogramming.com/red/chapter08.html
> So, basically, what you're saying in other words is, that even though
> I have texture size limitation X, I can use (for instance) 9 textures,
> each with this limitation?
Wolfgang
Miha
Feb 2, 2012, 5:37:25 AM2/2/12
to
On Feb 1, 11:12 pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
as I write this.
Having not read the chapter, I have some further questions.
I see you suggest using glTexSubImage2D. My understanding was that
this function would only be applicable if I were to use only parts of
the "bigger" texture?
Also, for reference, I am referencing the code (I'm not a fan of
pasiting large portions of code in newsgroups) the code below which is
executed for each "draw()" funcion call. Note however, that draw() is
not executed in a loop, but only when changes occur (framebuffer
updated, translation, etc).
Perhaps I'm doing something wrong in the draw() function...
(probably?)
The code: http://pastebin.com/tkARGb8Q
BTW, the vertices define only two triangles (4 points) that form a
rectangle.
Kind regards,
Miha.
wrote:
> See this chapter of the Red Book, especially figure 8-9 is of interest
> for your:http://glprogramming.com/red/chapter08.html
Wolfgang, thank you for an excellent link to a book. I am reading it
> for your:http://glprogramming.com/red/chapter08.html
as I write this.
Having not read the chapter, I have some further questions.
I see you suggest using glTexSubImage2D. My understanding was that
this function would only be applicable if I were to use only parts of
the "bigger" texture?
Also, for reference, I am referencing the code (I'm not a fan of
pasiting large portions of code in newsgroups) the code below which is
executed for each "draw()" funcion call. Note however, that draw() is
not executed in a loop, but only when changes occur (framebuffer
updated, translation, etc).
Perhaps I'm doing something wrong in the draw() function...
(probably?)
The code: http://pastebin.com/tkARGb8Q
BTW, the vertices define only two triangles (4 points) that form a
rectangle.
Kind regards,
Miha.
Wolfgang.Draxinger
Feb 2, 2012, 9:47:34 AM2/2/12
to
On Thu, 2 Feb 2012 02:37:25 -0800 (PST)
Miha <miha.v...@gmail.com> wrote:
> Wolfgang, thank you for an excellent link to a book. I am reading it
> as I write this.
Well, actually this is a rather outdated version of the Red Book. If
Miha <miha.v...@gmail.com> wrote:
> Wolfgang, thank you for an excellent link to a book. I am reading it
> as I write this.
you want some more modern text I recommend http://arcsynthesis.org/gltut
I, too, am writing a OpenGL textbook, but it's still far from being
finished. Also it's not so much aimed at the beginner, but intermediary
level.
> Having not read the chapter, I have some further questions.
>
> I see you suggest using glTexSubImage2D. My understanding was that
> this function would only be applicable if I were to use only parts of
> the "bigger" texture?
image. Of course the specific part may as well be the whole image. The
advantage of using glTexSubImage over glTexImage is, that it writes
into an existing, already initialized buffer.
The use of glTexSubImage for updating texture data was a clear
intention of the API, which you can see by the fact, that passing a
null pointer as data parameter to glTexImage will initialize the
texture and buffer, and copy data to it.
> Perhaps I'm doing something wrong in the draw() function...
> (probably?)
>
> The code: http://pastebin.com/tkARGb8Q
> BTW, the vertices define only two triangles (4 points) that form a
> rectangle.
It's not necessary to delete the texture if you want to create new one.
Just reuse the existing ID.
http://pastebin.com/H8Zrt7zr
Wolfgang
Miha
Feb 2, 2012, 5:12:57 PM2/2/12
to
On Feb 2, 3:47 pm, "Wolfgang.Draxinger" <Wolfgang.Draxin...@physik.uni-
even more clearer.
> I did a few changes, mostly about how the texture object is managed.
> It's not necessary to delete the texture if you want to create new one.
> Just reuse the existing ID.
Thanks a lot! I also saw that I don't need to update the texture on
each draw (for instance, when I zoom & pan, the texture does not need
to be reloaded). The performance wen't up by a few orders of magnitute
just disabling this. (for instance, I get up to 5 udpates per second,
but when you pan or zoom, you get 20 or even more redraws per second
so I wasted a lot of the CPU cycles updating the texture).
I still need to figure out a nice way to create tiles. Is it perhaps
possible to map multilpe textures to the same rectangle? Width
different UV mappings?
Also, currently, my plane is 1 wide and 1/ratio tall. I guess it could
be 100 wide and 100/ratio tall having adjusted the viewport
accordingly? Having tiles each 1 wide would help me scale it more
accurately - I think I might otherwise have problems with float
accuracy (i.e: tiling 2500 px wide image to 5 tiles each 1 wide and
applying 4x512 texture and 1x 512px texure UV mapped to 452/512.)
Thanks,
Miha.
muenchen.de> wrote:
> glTexSubImage replaces only a specific part of the existing texture
> image. Of course the specific part may as well be the whole image. The
> advantage of using glTexSubImage over glTexImage is, that it writes
> into an existing, already initialized buffer.
Thanks for the explanation. Also, seeing your code changes makes it
> glTexSubImage replaces only a specific part of the existing texture
> image. Of course the specific part may as well be the whole image. The
> advantage of using glTexSubImage over glTexImage is, that it writes
> into an existing, already initialized buffer.
even more clearer.
> I did a few changes, mostly about how the texture object is managed.
> It's not necessary to delete the texture if you want to create new one.
> Just reuse the existing ID.
each draw (for instance, when I zoom & pan, the texture does not need
to be reloaded). The performance wen't up by a few orders of magnitute
just disabling this. (for instance, I get up to 5 udpates per second,
but when you pan or zoom, you get 20 or even more redraws per second
so I wasted a lot of the CPU cycles updating the texture).
I still need to figure out a nice way to create tiles. Is it perhaps
possible to map multilpe textures to the same rectangle? Width
different UV mappings?
Also, currently, my plane is 1 wide and 1/ratio tall. I guess it could
be 100 wide and 100/ratio tall having adjusted the viewport
accordingly? Having tiles each 1 wide would help me scale it more
accurately - I think I might otherwise have problems with float
accuracy (i.e: tiling 2500 px wide image to 5 tiles each 1 wide and
applying 4x512 texture and 1x 512px texure UV mapped to 452/512.)
Thanks,
Miha.
Miha
Feb 6, 2012, 2:58:11 AM2/6/12
to
Hi!
Just wanted to thank you again and let you know that I've successfully
implemented tiling funcionality and have tested it with large images
without problems.
Kind regards,
Miha.
Just wanted to thank you again and let you know that I've successfully
implemented tiling funcionality and have tested it with large images
without problems.
Kind regards,
Miha.
jbwest
Feb 7, 2012, 8:28:11 PM2/7/12
to
"Miha" <miha.v...@gmail.com> wrote in message
news:50e17785-456c-4e3e...@p21g2000yqm.googlegroups.com...
jbw
Miha
Feb 9, 2012, 2:00:14 PM2/9/12
to
No, I have access to remote framebuffer (RGBA).
Miha
Miha
0 new messages