Well of course not, but why not do it anyway?
![Smile :)](./images/smilies/ms-smile.png)
That's a fair point, before I stopped working on it I had started experimenting with FFI in my software implementation but hadn't got as far as an FFI framebuffer. It was a while ago but IIRC I used it in the texture mapping as sampling the default image object was slow. I'd gotten bored of it by that stage, but I still have the code for that version somewhere so I might give the FFI framebuffer a go and see how it changes things.Plotting the pixels on a frame buffer is really fast if you use FFI and pointers.
I'd be curious to see how your performance changes when you have sprites implemented, the "plotting pixels" statement above really also includes the overdraw you get with sprites, especially if you have a really close one or two, you can end up filling up the whole screen a second or third time. Depending how you implement that you can reduce it massively though. If you use a z-buffer and sort your potentially visible sprites every frame you can probably eliminate sprite-over-sprites. I didn't bother sorting mine in the software version, and the GPU version can brute-force it so didn't bother then either.