[fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/12/2017 10:30 AM, Marco van de Voort wrote:
> In our previous episode, Graeme Geldenhuys said:
>> Speed:
>>     In recent graphics work I've done, I've noticed that FPC is fantastic
>>     at created cross-platform applications. But the generated binaries
>>     are NOT fast at all - no matter how many compiler parameters and
>>     artificial speed optimisations we tried to implement. Sloppy Java
>>     code ended up 3x faster than the best I could get out of FPC
>>     generated binaries.
> (Quite confusing paragraph mixing up graphics (which is typically bound in
> speed by the drawing API that you use) and generated code speed, what did
> you actually mean?)
Indeed, Graeme's example (a software raytracer) has absolutely *nothing* 
to do with the slowness of the win32/win64 graph unit. The bottleneck in 
the graph unit implementation is the speed of the windows gdi drawing 
routines, which were never really designed to be used in the way Turbo 
Pascal's graph unit works. Because the TP7 graph unit was designed for 
DOS, where you get direct access to the video hardware, normally, 
there's simply no concept for double buffering. TP7 graph unit programs 
never really render a full frame and then call SwapBuffers(), they just 
draw on the screen and it's immediately visible. The way the win32/win64 
graph unit is implemented, is by effectively doing the equivalent of 
SwapBuffers() after each graph procedure/function call that draws 
something. Ptcgraph uses a different approach and that's why it is in 
practice much faster. All the ptcgraph graph drawing procedures and 
functions render to a software framebuffer, which is periodically 
blitted to the screen in a separate thread (at about 60 fps, but the 
framerate isn't really controlled). This works great, especially on 
modern multicore CPUs. Of course, this goes up to a point, where the 
resolution gets too high for software rendering and the framerate drops 
somewhat (but this happens at Full HD resolutions, that TP7 programs are 
unlikely to use - and even there the speed may be acceptable, if the CPU 
is fast enough). The main disadvantage is that you get a CPU core loaded 
at 100%, but this isn't really that much worse, compared to what certain 
"modern" applications do :) I even know a happy ptcgraph user, who uses 
ptcgraph in Full HD resolutions on a Raspberry PI. :) So, please, try 
ptcgraph and see if it makes a difference for you.

Best regards,
Nikolay