I’m trying to write a program that displays images.
It should be possible to rotate (90 degree steps only),
zoom in and out and move the images inside the window.
My problem is, that these images are very big and I my
program segfaults, when I try to load them as textures.
I also tried glDrawPixels but when displaying the whole
image and moving it around it gets very slowly.
Is there a way to especially move such a big image
efficiently?
can you post some code? and can you tell how big is “very big”? you can use glGet(GL_MAX_TEXTURE_SIZE, …) to determine the maximum texture size that your gl implementation allows.
@RigidBody
One of the images has a size of 2953x2479 pixels and a resolution
of 300 dpi. It is a tif-image which needs 22Mb disk space.
And it is possible, that there will be even bigger ones.
What code do you want to see? As I wrote above, I simply tried
something like this:
Here I have the problem, that the image isn’t drawn, when the
origin of the image has a negative value. I don’t know how to fix
this, but because I didn’t know, if I will later still use
glDrawPixels I left this bug in the test version.
@songho
But what if the whole image can be seen? Then the whole image has
to be loaded as well. And this is the case when it gets slowly.
When the zoom factor is higher and only a small part of the
image can be seen, then the performance is ok.
hm…concerning the visibility: afaik, the position which you define with glRasterPos must be inside the viewport (after being transformed with the modelview and projection matrices), otherwise the image is not drawn.
just a thought- try to scale the image- in both directions- to have a size dividable by 8.
Swald, as API hinted at, you should probably be using a texture to draw your stuff, not DrawPixels (very slow by comparison). You can map in portions of the image as needed/viewed with glTexSubImage for example.
With this basic technique the texture size is virtually unlimited. You could use this in conjunction with Songho’s grid idea and display massive images indeed.