[Lazarus] Fast drawing to canvas

[Marco van de Voort]

On Thu, Feb 23, 2012 at 06:49:38PM +0100, Reimar Grabowski wrote:
> > Benchmarking with own code. I had enabled gl3 contexts and PBOs, and I saw
> > that that was faster on new machines, but slower on older ones. Old and new
> > was mainly videocard. (HD5400 series from ATI vs older GF8500's)

> This is not only old vs new it is also ATI vs NVidia and it is only two
> cards.  Nothing wrong with that but I would not draw general conclusions
> from that.

It is sufficient indication that one and the same binary must be able to do
both. Regardless if that is between vendors or not.


> Enabling PBOs sounds like there is a specific way to use them but there
> isn't.  Using one, two or a pool of PBOs are the options you have for
> using them for this case and they all should differ in speed (and
> implementation complexity).

Of course not. You can test OpenGL version and extensions and conditionally
execute code accordingly.

> I have not tested this but reliable sources (forum on OpenGL.org) say that
> how and when you map/unmap the buffer makes a difference, too.  Before
> mapping the buffer calling glBufferData with null as data may speed up the
> mapping time.

> > I simply measure my frame upload method times, which are zero copy in my own code, thus entirely bound by opengl.

> It sounds like you measure OpenGL call blocking time which may or may not
> be equal to the real upload time.

I do. But for me that is the interesting benchmark. And though I readily
admit that I only started to scratch the surface of testing the various
performance aspects, I do present realistic benchmarks of about 2 days
efforts spent on the issue.

>  If you use PBOs you most likely map/unmap the buffer in that method, too,
> which I don't consider upload time.

It depends on your purpose. I'm in computer vision, and I want to show my
frame as soon as possible. If you know a way to fire an event after upload
is finished, don't hesitate to mention it. As long as I don't have that, I
have no choice than to block on it.

This is not a game where you just fire all textures on level load, and just
proceed and block at the end, hoping that every paralellizes as much as
possible. 

>  I don't want to question your method just saying that measuring OpenGL
> times is not as straight forward as it seems to be.

No doubt about that.

>  That's why NVidia provides a complete SDK (PerfSDK) to measure your
> OpenGL performance.  In the OpenGL world nothing is as easy as it seems.

Nvidia's border conditions are typically not my own. And in practice only
real-life (read: average) performance is usuable. Peak performance under
idealized circumstances is a mere footnote.

> > so the opengl call blocking time is not entirely the same as the time the card is busy
> Of course not. That's how OpenGL works and what makes timing single OpenGL operations difficult.
> 
> Nonetheless some interesting info you gave there.

(*) average uptime of our machines. Reasons for reboot are often external to
the application (read: powerdown the entire productionline for machine maintenance)