ZodTTD: Home Of Homebrew

For those in the Unites States, you may be eating up turkey with the family…But me, well I’m giving my thanks in a different way. I couldn’t stop playing with this framebuffer code for the iPhone I mentioned earlier. I now know of the two framebuffer addresses and how to retrieve them individually.

Why is this important? Well it’s all about my emulator’s performance in our case!

But are you willing to give up transparent overlays in landscape mode for this performance boost? Remember for this to work it will draw on top of every area I write to. So if you are in landscape mode, for performance reasons I can’t draw an opaque overlay on top of each frame I draw. And blending a semi-transparent overlay is out of question. What we are left with is possibly to center the emulator screen in the center, and have controls on the sides. Leaving the controls outside of the emulation screen could let things work.

Some quick benchmarks I ran show the average blit to a CoreSurface buffer to draw to the screen takes between 5 and 13ms per blit. It spikes constantly from that 5ms. If I simply have it write to a different buffer that is malloc’d, the blit takes less than 1ms. While this isn’t scientific, it indicates to me that the traditional way of writing to the screen via CoreSurface, while better than OpenGL ES (for this type of blit) and CoreGraphics, is still very slow. This is where getting a lower level access to the screen’s pixel data comes into play, and hence the framebuffers.

I noticed writing to the first framebuffer with CoreSurface ID 1 (more on this in a sec) is about the same speed as writing to a CoreSurface you can create on your own. The magic happens when you write to the second CoreSurface ID 2. The above test of 5ms – 13ms goes down to 2ms! Much better, considering you only have 16ms to deal with when running at 60 FPS.

So how do you access these framebuffers? Leaving behind the complex code mentioned earlier, here’s how. First add the CoreSurface framework to your project. Then:

extern void* CoreSurfaceBufferGetBaseAddress(CoreSurfaceBufferRef surface);
extern void* CoreSurfaceBufferLookup(long lookup);
...
void* framebufferID1 = CoreSurfaceBufferGetBaseAddress(CoreSurfaceBufferLookup(1));
void* framebufferID2 = CoreSurfaceBufferGetBaseAddress(CoreSurfaceBufferLookup(2));
...


Simple as that! You now have a pointer to each framebuffer. Simply write your ARGB pixel data straight to it!

Maybe psx4iphone could use this technique for an added performance increase?

Thanks,

ZodTTD

For those who have been long time followers, you probably saw how much I hoped to be able to write to the iPhone and iPod Touch’s video framebuffer. My reasoning was that I would not need to use the taxing call to “setNeedsDisplay” to render all the UIKit elements down to the framebuffer, increasing the performance of my emulators and ports. This basically would skip the middleman that is Apple, and get me closer to something like /dev/fb of NIX.

Recently I was speaking to crash-x and others in saurik’s IRC about the framebuffer. It seems the devteam, in particular planetbeing, has been able to write to the framebuffer ever since redsn0w. Due to devteam’s strict privacy policy he was unable to make this public. At least that is what I hear was the case. This saddens me as it was Steven Troughton Smith and I’s work figuring out how to read the framebuffer for Veency’s use, that probably led to his discovery.

Either way, moments after crash-x and I dug into redsn0w, I had a working example for writing to the framebuffer. It’s not ideal for most people out there, and can’t be used for AppStore apps, but it’s the holy grail of blitting a fullscreen buffer of pixel data repeatedly. And this is exactly what emulators tend to do. What I found out however, is my emulators are set up to still require setNeedsDisplay to swap video buffers. This is not ideal for performance sake. Until setNeedsDisplay can be removed from the equation, I don’t see the following example of writing to the framebuffer too useful for a series of blits.

Here’s the code:

IOMobileFramebufferRef connect = NULL;
kern_return_t result;
CFMutableDictionaryRef dict;
CoreSurfaceBufferRef screenSurface = NULL;
unsigned char* screenbuffer;
// Probe possible framebuffers
io_service_t framebufferService = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleH1CLCD"));
if (!framebufferService)
{
framebufferService = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleM2CLCD"));;
}
if (!framebufferService)
{
NSLog(@"Nothing found to draw too!");
}
result = IOMobileFramebufferOpen(framebufferService, mach_task_self(), 0, &connect);
result = IOMobileFramebufferGetLayerDefaultSurface(connect, 0, &screenSurface);
CoreSurfaceBufferLock(screenSurface, 3);
// Add to a CALayer here if you want
//
// Get the framebuffer's address to be written to and store it in screenbuffer
screenbuffer = CoreSurfaceBufferGetBaseAddress(screenSurface);
CoreSurfaceBufferUnlock(screenSurface);
// write to screenbuffer like so
// draws a fully white screen
// The screen is 320x480 and seems each pixel is 4 bytes ARGB
memset(screenbuffer, 255, 320*480*4);

I’ll fiddle with this code some more to see if I can remove the need to setNeedsDisplay to swap buffers, and simply check if it will actually improve performance as well. Updates to come!

Thanks,
ZodTTD