IPAD must-haves. And fun-to-haves.

Brighten your iPad with a colorful cover, stream to your TV, download pictures from your digital camera, and more. There’s already so much you can do with iPad and iPad mini

Apple Wireless Keyboard

The incredibly thin Apple Wireless Keyboard uses Bluetooth technology, which makes it compatible with iPad

Apple unveils iPad mini: ‘Thin as a pencil, light as paper’

iPad inspires creativity and hands-on learning with features you won’t find in any other educational tool

Lightning connector and FaceTime HD camera

Apple announces 4th generation iPad packing an A6X CPU

Pages

Showing posts with label requested. Show all posts
Showing posts with label requested. Show all posts

Thursday, March 14, 2013

OpenGL advice requested

Very new to programming OpenGL on Mac, here.  But here's my goal...

 

I want to display a Windows BMP-formatted image onto a full-screen second 1920x1080 display.  Such images are in BGR-byte order (no alpha) and are likely not to be powers-of-two in size.  This seems to be a problem for the Mac.

 

I've looked into glTexSubImage2D and glTexImage2D, but it's entirely unclear which (if any) current Mac video cards support GL_BGR (or GL_BGR_EXT) as a pixel source format.  Some indications are that NVidia supports BGR (eg. Quadro 4000), whereas current Radeon-class cards do not.

 

I won't want to resort to twiddling the B-R bytes in RAM as that will likely be too slow, even if it were heavily threaded on a multi-core CPU.  Swizzling on the GPU is a possibility, I suppose, if it were much faster -- particularly with the likelihood of upcoming K-4000 class Kepler cards destined for the Mac.  (Side note: if conversion to RGBA is a required step in RAM, is that frame buffer then available to CoreAnimation or some visual effects?).

 

The reason I want the code to be so fast is the high potential exists to have the BGR-image delivered from an uncompressed AVI file instead, in which case such processing needs to occur at 30fps.  So, I need a sustained data rate of approximately 190MBps.  Add to that 16 to 20 rectangular regions will determine a final frame, possibly from different data sources. I suspect double-buffering in GL will be a given.

 

And, again, I confused if using PBO's - FBO's are overkill in this situation, or if they're even required.  It would be great to have direct access to the screen buffer with some IOKit stuff like IOFBBlitSurfaceCopy but from what I've read some of those types of solutions are very much deprecated/unavailable in OS 10.8.

 

Another side note: if CPU processing weren't a constraint, I suppose any compressed media could be used (eg. compressed MOV) as a source, but that's pipe dream.

 

Ya… so…at the top end I'm asking for an OpenGL (or Quartz2D) solution to playing an uncompressed AVI @ 30fps.  To this end, there's an impressive (but dated) tutorial by NeHe on "Playing AVI files in OpenGL", but he too resorted to twiddling B-R bytes -- I don't really want to have to go there.  I attempted to rejig his tutorial to use GL_BGR_EXT source formats, but got nothing but white.

 

Can anyone offer any advice?  A start with very quickly displaying BMP (BGR) images would be great.

 

-- bp


View the original article here

Wednesday, March 13, 2013

Re: OpenGL advice requested

Imagine that your Mac's video card is connected to a hardware device that appears as a second 1920x1080 DVI monitor.  That hardware device segregates the display into 4 separate 960x540 external displays.  I need to run 4 separate uncompressed AVI's @ 30fps on those displays.  Does that provide a better idea of what I'm doing?

 

Well, by low-level, I mean that I'm not going to go and do this with a unsupported AVI files because, well, I can't...

     src = CGImageSourceCreateWithURL ((CFURLRef)url, NULL);

     image = CGImageSourceCreateImageAtIndex(src,0,NULL);

     context = CGBitmapContextCreate...

     ...

     CGContextDrawImage...

 

Relative to these high-performance API's, I call "fread" low-level.

 

The fact that Apple supports BMP is not helpful to me in this situation unless I can open a large (>4gb) uncompressed AVI file and point to a section of it and say to the API... "look, heres some BMP data!  Use it!".

 

Hopefully you can see my need for fast access to the GPU.


View the original article here