Re: NSGLImage doesnt open large images
Re: NSGLImage doesnt open large images
- Subject: Re: NSGLImage doesnt open large images
- From: "E. Wing" <email@hidden>
- Date: Thu, 10 Mar 2005 17:58:08 -0800
> From: "Pradeep Kumar" <email@hidden>
> Subject: Re: Re: NSGLImage doesnt open large images
>
> Hi John
>
> Yes, there is a query for this. I get a value 2048. So whenever the image size is greater than
> 2048 pixs in width or height the image doesn't display.
Yes this is a limitation generally imposed by the underlying hardware.
OpenGL is geared towards fast direct access to the video hardware. As
such, you must also respect the contraints of the hardware and its
mechanisms for ensuring things remain fast. Also, keep in mind that
this value will be different for different video cards. Also with some
implementations (not necessarily Mac, but I've seen it before on some
other platforms), the higher numbers are emulated in software so it
can get really slow at high resolutions, even though the query passes.
To deal with textures that are larger than the max texture size, you
can chop up your image into smaller pieces and feed those to OpenGL.
The downside is that you have to write code to manage the tiling.
>However there are some images
> which are less than this size which doesnt display properly. Although openGL doesn't report
> any error for such images, it displays garbled up. It's like there is some difference in the
> parameters between the image and the parameters that are used by openGL. It's like some
> kind of mismatch in the row bytes.
This could be many different things. First, make sure your textures
are always a power of 2. This is an OpenGL requirement (with a few new
exceptions). If the dimensions aren't powers of 2, then it might not
render (though I've seen some implementations render it anyway, but
it's unpredictable).
Another problem may be related to how your image data is stored. With
some formats, there is extra padding with non-image data to help align
data with the memory architecture of choice. Thus the "width" of the
image isn't actually the "width" of the data file (row). I've seen the
term "pitch" used to describe the width of the data. So it is possible
that pitch >= image_width. When you load the data into OpenGL, you
will need to tell it the information about how your data is stored.
(There there is the usual stuff like bytes per pixel and byte
ordering.)
Another note about the power-of-two issue, there is an extension
called TEXTURE_RECTANGLE_EXT which allows you to submit
non-power-of-two textures to OpenGL. It seems to work by chopping
textures into smaller power-of-two pieces for you.
Another thing about this extension is that it might allow you to
submit larger textures than the max texture size, though I've never
tried it. I think it has a separate max size query.
Check out the notes at:
http://developer.apple.com/graphicsimaging/opengl/extensions/ext_texture_rectangle.html
Keep in mind that this is an extension and might not be available
everywhere. I think all Quartz Extreme capable computers support this
extension, but I'm not totally sure on that. (The mac-opengl mailing
list would proably be the place to ask about this.)
> I am reconsidering the use of openGL for displaying images because of these issues unless
> someone has a way to solve this problem.
OpenGL is the way to go if you need fast access to the hardware for
performance critical stuff. But it involves more work and you forgo
many of the nice things Cocoa gives you. If performance isn't that
critical and you are well versed in Cocoa, you might find that
sticking with the Cocoa/Quartz2D APIs is better for you (assuming they
can meet your requirements).
Hope this helps,
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden