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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
