>>This is not the reason for the performance difference, native controls are ultimately bitmaps as well and have added overhead in being registered with the operating system as windows. The biggest issue is that VB forms are pre compiled and VFP forms are instantiate piece meal.
>
>Are you sure about this? My understanding is that VB can make Windows API calls to paint the form controls, while VFP cannot use the API calls, thus slowing down VFP.

You misunderstand. Both VFP and VB use various elements of the Win32 API to draw components on screen; VB uses native Windows controls, which can be manipulated individually rather than treating the whole of a form as a bitmap to maintain and manipulate, as is the case with VFP's native application-drawn controls. In environments where the management of the Window can be offloaded from the main application, as is the case with many thin client solutions, using native Windows controls lets the UI end operate with less bandwidth than VFP's bitmap manipulation - it costs less to pass a Windows command to a control rendered client-side than to pass a redrawn bitmap each time a control is updated. The same amount of total work is being done, whether the control is rendered by the application or through client rendering of a Windows command; the bitmap which represents the form has to be updated IAC, it's a matter of how much data passes between the form and the GDI layer doing the rendering. VFP doesn't do it's own rendering really, either, it uses the Win32 API to update the virtual form, but the app rather than the OS takes responsibility for the rendering.