Sorry if this has been asked before.... I did some searching of the
archives and didn't find anything, so here goes....
I am looking to code up a Image viewer that I would like to get some
serious performance out of. Real time zooming, panning and rotation
of high resolution images, infinite zoom in and out, etc. I am
looking for some initial advice to see which way I should go for the
graphic interface Quartz (core image, core graphics,etc.) or OpenGL.
If you are interested in the OpenGL route, you might look at:
I've seen some really, REALLY large, high resolution images manipulated
in real time through Apple's OpenGL implementation.
Some image formats will be supported by the OS (JPEG, TIFF, etc), and
others I will need to write my own decode routines so I can work with
raw bitmaps.
In any event you are going to have to get the images into memory so you
can either upload them to VRAM or map them into textures for OpenGL.
You can use the system to import JPEG and TIFF images into image
buffers. In short everything will end up being "raw bitmaps" at some
point.
You mentioned Core Image later so if you have access to a Tiger seed
you might also want to look into Image I/O.
But the future functions of Quartz and the Core Image seem appealing
as well... Real time
transparency and layering of images, etc..
From your brief description, don't know that Core Image is going to be
very useful. Core Image is a tool for applying effects to images.
Unless you are going to be doing something like applying false color to
your maps (seems like a reasonable thing to do in a map viewer), then
Core Image may be of limited use.
OpenGL can handle transparency and layering of Images as well. As you
note in a comment later on, Quartz 2D and Core Image both will use
OpenGL to achieve greater performance (more so in Tiger than in
previous releases).
In the end, the the tradeoff will likely be one of Performance vs.
Complexity. Writing your code in OpenGL requires your application to
pay attention to a lot of details (what kind of graphics card is on the
machine, what OpenGL features does that card support, what texture
sizes can it handle, does it have a programmable GPU, etc...) This
makes the OpenGL code a bit more complicated, but since you're "closer
to the metal" you have the potential for higher performance. Quartz 2D
is a much easier API to write to and it insulates you from the details
of the underlying hardware, but you may lose some performance. (Or at
the very least you you will have to code Quartz 2D carefully to get
performance close to the OpenGL route).
I guess I am a little confused since it seems like the two
technologies are somewhat overlapping in some respects (in fact,
doesn't Core Image use OpenGL to a degree?). And for me the learning
curve will be equal, so that doesn't sway me in either direction. Any
suggestions???
As I alluded to before OpenGL is programming closer to the metal. Just
as assembly requires you to juggle more details than C/C++ so do does
OpenGL require you to know more of the details of the particular
hardware you are running on. However, just as in the assembly vs C/C++
case if you manage that complexity well, you can get much higher
performance.
I don't think the learning curve will be nearly as steep to adopt
Quartz 2D and your code will be much easier to follow. Potentially it
will be much easier to get your code to run on a broader range of
computers as well (since Quartz 2D will abstract you farther from the
hardware). But again, it's a tradeoff of complexity for performance.
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
