50fps windowed, ~100fps fullscreen on macbook pro. If that is a bunch of SetPixel calls, then yes, the calls themselves will most likely be the bottleneck. Maybe it makes sense to add something like SetPixels where you’d pass a whole width*height array. Should speed up those things quite a bit.
This is most likely saying that the demo is cpu bound rather than gfx card bound. Probably due to the scads of SetPixel calls. And the MacBooks and Mac Minis do have decent cpus in 'em.
a) A fill command which can fill a rectangle area (x1,y1,x2,y2) with a given colour (ARGB).
b) A copy command with which you can copy from one area/texture to another area/texture.
c) What’s exactly happening with the commands? Can i access the textures in the VRAM directly?
Right now SetPixel updates pixels in system memory copy; GetPixel reads from system memory copy. Apply() uploads the texture to the graphics card (glTexSubImage*).
That is generally not possible. VRAM is not mapped to process address space, so you can’t “just write” to it. In OpenGL textures are modified using glTexSubImage* calls.