[Lazarus] Fast drawing to canvas

[Reimar Grabowski]

On Sat, 11 Feb 2012 09:56:21 +0100
Felipe Monteiro de Carvalho <felipemonteiro.carvalho at gmail.com> wrote:

> On Fri, Feb 10, 2012 at 7:58 PM, Reimar Grabowski <reimgrab at web.de> wrote:
> > 2D projection functions have never been part of OpenGL AFAIK, mind telling me which functions you talk about?
> 
>   glMatrixMode(GL_PROJECTION);
>   glLoadIdentity;
>   glOrtho(0, OpenGLControl1.Width, OpenGLControl1.Height, 0, 0, 1);
You are right, I forgot this one.

>   glMatrixMode(GL_MODELVIEW);
>   glLoadIdentity();
These are all deprecated but still available since OpenGL 3 (2008) and removed in 3.1 (if you create an OpenGL 3 and up only context - 2009), as they belong to the fixed function pipeline. They were run on the CPU anyway so if you really need this kind of matrix manipulations you can just implement them yourself (as most people using OpenGL have done anyway since you need to know your matrices for many tasks and OpenGL had no fast way to retrieve them).

>   glDisable(GL_DEPTH_TEST);
>   glViewport(0, 0, OpenGLControl1.Width, OpenGLControl1.Height);
>   glGenTextures(1, @TextureId);
Still available.

>   glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
Not needed anymore due to GLSL.
 
> > And nobody forces you to use ES 2 just use 1.x if you like it more.
> 
> Since it is version 2 I suppose people will start dropping support for
> version 1 in the future.
That's not how it normally works in OpenGL. You could use OpenGL without the fixed function pipeline since 2.0 (2004). Support was removed in 2009 and only if you ask for a special context. If you use a 'standard' context OpenGL 1.0 code (1992) works on current gen graphics hardware unchanged (unlike old DirectX code).
Perhaps on phones they are a little bit faster to deprecate old stuff but I don't think vendors will drop support soon.
 
> lol! But just read any OpenGL tutorial which you can imagine. It
> always starts with glBegin, glEnd and boom ... doesnt work in OpenGL
> ES. And, read the code here:
glBegin and friends (called immediate mode) was unefficient since 1997 and a bad idea to be used in production code. Normal mesh sizes start around 1000 vertices nowadays most are much larger. You do not want to specify such structures with glBegin/glEnd. You must layout your data in special ways to get the most from your hardware. This is just not possible with glBegin/glEnd.
Yes, it was used a lot in tutorials but that doesn't change the above.

> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/fpvectorial/examples/fpv3d_mainform.pas?root=lazarus&revision=35186&content-type=text%2Fplain
> Which part of this code works in OpenGL ES 2? And it isnt even 2D, it
> is 3D triangles. Anything from it works at all?
This still works:

glClearColor(1.0, 1.0, 1.0, 1.0);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
glEnable(GL_DEPTH_TEST);

:)

The rest no, as it is either immediate mode or fixed function matrix stuff.
You need to learn GLSL (a C like language that runs on the GPU) to do anything in modern OpenGL or OpenGL ES 2.x.

> But my real question is: how can you have 1 code for all those OpenGL
> versions to draw 2D bitmaps? Seriously, Id like to know.
Of course you can't. On modern hardware (later than 2004) you should use the programmable pipeline for best performance (not available on old cards) and even if you use the old fixed function pipeline it is emulated with GLSL programs and slower than doing it yourself since too much legacy stuff is supported. OpenGL is a low level API and it's design reflects the rapid advances in graphics hardware.
OpenGL is suitable for doing 2D stuff but it's main purpose was always 3D rendering.

> If it is
> impossible then how can one say they are very similar?
To quote wikipedia:
OpenGL ES 1.0 is drawn up against the OpenGL 1.3 specification,
OpenGL ES 1.1 is defined relative to the OpenGL 1.5 specification and
OpenGL ES 2.0 is defined relative to the OpenGL 2.0 specification.

So OpenGL ES is very similar to OpenGL.

> For me, not beginner friendly is a very strong indicator of a bad design.
OpenGL is a low level graphics lib, as bare to the metal as you can get with regard to graphics cards, so it reflects the state of the hardware. Ease of use is only a second thought, performance is the important metric. It is meant for graphic programmers that are familiar with the concepts.
If you need something simpler you should not use it directly but a graphics lib that builds on top of OpenGL optimized for your use case (there are some GUI libs out there).
Graphics programming is a complicated topic. Your use case is simple in your eyes (because you never had to worry about how the gfx card actually does its job, coming from software rendering/drawing), but it is not so common for interactive 3D graphics, where some simple quads are good enough for a GUI (like in any current game) and most of your time is spent pushing millions of vertices to the graphics card animating them and doing advanced lighting and other effects. Naturally OpenGL is more optimized for the later tasks than the former one.
Please don't bash it based on insufficient knowledge about the topic. The code you posted was the way to use OpenGL before 1997 (when VertexArrays were introduced) or 2004 (when the programmable pieline was introduced) and you complain that it does't work like that anymore in 2012. Well, times have changed and hardware a lot, too. Some simple stuff got more complicated but many complicated stuff became a lot simpler and you now have a lot more options.

R.