When you look at the differences between the GF version and the same code converted to OpenKODE/EGL, you find that there
 aren't that many differences. However, making those changes, even if there are just a few, isn't always easy...

The two big differences for GF apps rendering in OpenKODE windows are:

1) no layers; that's because with GF, the only "compositing" strategy is to use display controller layers. The 
compositied windowing system that handles OpenKODE windows can use other hardware like 2D cores, VG cores, or 3D cores.

2) different surfaces; you have to use EGL surfaces and not GF surfaces.

If in the end each application has its own layer, you don't necessarily need the composited windowing system. The same 
thing can be done with plain GF. However, OpenKODE also gives you better events, delegates (which can be used to control
 other GF apps), and allows you to have multiple applications on the same layer (only one visible at any point in time).
 All of this cannot be done using GF only.

http://community.qnx.com/svn/repos/graphics/trunk/apps/kd/tutorials/gf-kd-vsync/gf-kd-vsync.c is the OpenKODE equivalent
 of http://community.qnx.com/svn/repos/graphics/trunk/apps/egl/tutorials/gf-egl-vsync/gf-egl-vsync.c

gf_draw_blit2 and gf_draw_blitscaled can still be used quite easily if one of  the surfaces (source or destination) 
isn't an EGL surface. If you need to blit from an EGL surface to another EGL surface, you have 4 options:

1) blitting can be done with a Khronos rendering API like OpenGL ES, or OpenVG. In this case, you cannot blit directly 
from an EGL surface to another EGL surface. The source must be an object like a VGImage or a GL ES texture.

2) Use the EGL_QNX_gf_surface extension which will give you the gf_surface_t corresponding to the current renderbuffer 
of an EGL surface. This obviously only works if the EGL_QNX_gf_surface extension is supported, which may not always be 
the case.

3) Use the EGL_KHR_lock_surface extension, which allows software renderers to write their output to EGL surfaces. With 
this extension, you can get a CPU accessible address, the stride, and the bit offsets of each color component of an EGL 
surface. You can use gf_surface_attach and gf_surface_reattach to wrap it as a gf_surface_t. You will have to get the 
rest of the information from other calls, i.e. eglQuerySurface to get the width and height, and eglGetConfigAttrib to 
get the pixel format. Once an EGL surface is locked, it must be unlocked before you can do things with it, like 
eglMakeCurrent or eglSwapBuffers. Each time a surface is locked, the pointer and stride returned could be different from
 the last time. This is where gf_surface_reattach becomes useful...

4) Use eglCreatePixmapSurface for offscreen renderbuffers. The native pixmap is always a GF surface, which you can use 
as argument to gf_draw_blit2 and gf_draw_blitscaled. The EGL surface can be used as argument to eglMakeCurrent, etc.

Now, getting back to square one, depending on what you are trying to do, there might be an easier approach than the 
generic solutions I have outlined here.