Key Issues

Parallelization and Memory Bandwidth issue

XFDraw uses per face parallelization which can result can terrible performance if an entire face takes up the screen, as only one thread will be rendering it. Because of this XFDraw has custom screenspace shaders that handle parallelization per row, so using deferred rendering is strongly suggested.

Secondly, system RAM is much slower. Color buffers aren't kept in vec4 format, but rather integer format represented by the byte4 struct. Because of this, simply copy pasting OpenGL shaders won't work. Keep in mind that you can always store things in vec4 format and finally convert them into ARGB format at the end.

Pixel flickering

Another issue regarding per pixel parallelization is where some pixels "flicker through" other pixels, almost as if they were z-fighting. This usually happens because sometimes a two threads are simultaneously depth testing and writing to a pixel.

Solutions

1. Perform a late depth test

Right before setting your values you can compare your fragments depths with a reference to the depth buffers fragment with gl_FragDepth. You can see how to do this in the Shader Variables Tab

2. Use deferred rendering

The less time you take in your fragment shader the smaller the window is for pixel flickering.

3. Disable parallelization

Disable parallelization with the compile option CompileOption.UseFor. Note this will severely impact overall performance.

Parser limitations

Writing code like this will result in code that won't compile:

void main()
{
     if (statement)
          variableName = value;
     else 
          return;
}

The parser will merge else and return into elsereturn; which won't compile. This is due to the parser deleting all lines and merging everything into one long string to remove block comments. A fix should be released in a while.

Some structs are missing operators

Some structs are missing operators such as the vec4 struct. Additionally, some operators like vec3 * float must be in vec3 * float format and not float * vec due to how C++ handles operators.

Some math.h functions are slow

It is strongly recommended to use your own min, max and abs functions as for some reason the ones from math.h are very slow.

You can't read and write to the same buffer without any issues

I'm not sure if you can do this in OpenGL or not, however you cannot read and then write to the same buffer (ie a blur function). You will need separate input and output buffers.