[Gdal-dev] GDAL & OpenEV / MFC

[Marek Brudka]

Hi Matrin,

User Chapman, Martin wrote:

>Drawing speed is relative to hardware resources and other things you may have going on in your code while you draw.  So, there is no single answer to how much can GDI+ draw per second.  
>
Certainly! I was interested in exemplary results for examplary 
configuration to get an impression how fast GDI is. For rather cheap 
Geforces and not very fresh PCs one may render more 1MLines per second 
on 1280x1024 canvas. In general the number of triangles per second is a 
lower bound (often equal to :-) ) of the number of lines per second.

>What you could say is that given the same environment and variables, GDI+ will out perform OpenGL for 2D rendering on Windows.  Also, note that humans can only process graphics refresh rates of about 30 times per second, so drawing to the screen more times than that is useless.
>
I did not played with GDI (directly), hence I cannot compare it with 
OpenGL. This is why it's interesting for me :-).

However we made some tests using higher level libraries (Qt painter), 
which probably indirectly uses GDI (I'm not sure of that), and were very 
disappointed with the performance. In general, we found that  hardware 
accelarated OpenGL 2D vector rendering is at least 10 times faster than 
the using QtPainter functions. Certainly, the quality of graphic 
accelerator is important, but currently avalaible boards are usually 
optimized for 2D rendering.

If you compare **SOFTWARE** OpenGL with GDI, then your results are 
probably true. However, if the results are for hardware accelarated 
OpenGL and GDI, then they are at least curious, because OpenGL can 
render graphic directly on hardware, not via GDI. I think, that one 
should expect hardware accelarated OpenGL to be not worse than GDI, 
because if GDI uses hardware acceleration (does it?), then sooner or 
later does exactly the same what OpenGL, namely tells the accelarator to 
render something. It is hard to render something faster in software than 
in hardware, hence I doubt this result. Please also notice how graphics 
is managed in Windows Longhorn..

However very it is crucial how OpenGL is employed, because bad 
application of OpenGL usually results in poor performance.

>  Where OpenGL really suffers though, is filling shapes.  It has to tessellate each complex polygon before it can fill it and the gluTessellation functions are very slow.
>
OpenGL is as fast in filling triangles as possible and I doubt if GDI 
can do it faster. Tessellation is not an OpenGL function but it is 
provided by OpenGL Utility library. These two are distinct libraries!

Tessalation is usually done in software, not in hardware, hence one 
cannot expect it to be extremly fast. In fact, the tessallation is 
relatively slow, but excessive tessalation means, that software 
architecture is probably bad. One should almost always avoid 
tessalation. The best way to use it is to render an object once into 
glLists, then use this lists  as long as possible. Moreover, it is also 
important what is tessallated. The performance is seriously impacted if 
the shape tessallated is not convex and if it has inner rings. For a 
plain convex, solid shapes the tessalation is really fast, because the 
algorithm is very simple. In fact, for a plain convex polygons 
tessallation is not necessary, OpenGL can most of the work in hardware.

Maps in GIS application are not usually rendered periodically but rather 
asynchronously eg. map scale is changed, map contents is translated, few 
features changed their position/shapes etc. For a translation or 
sometimes scale changes, OpenGL provides excellent support, because 
usually it is enough to change model or camera matrix and call glList to 
obtain nicely rendered result.

OpenGL has excellent support for rasters. Obviously one has to convert 
them into textures, in fact GDAL does it, but the results are then 
impressive then. With a quite good accuracy, one may  also employ 
hardware accellaration do what GDALWarp is responsible for, namely to 
reproject raster maps.

And the last, but not the least about OpenGL. This library is not for 
rendering 3D graphics only! In your previous post in many places you 
wrote that OpenGL is slow because
it renders in 3D. OpenGL HAS a bunch of 2D functions, though their 
functionalities depend on capabilities of hardware accellaration.

I do not agree partially with you opinion about caching. For a mass 
market software one cannot assume PC has a huge RAM, hence it should 
rather render in immidiate mode without caching. But for specialized 
markets, where hardware is more controlled one may force to use PC with 
at least 512MB RAM. Please also notice, that in next the few years the 
average PC will probably have >1 GB of RAM and GIS might consume 512 
MRAM without any serious impact on performance. Well.., 512 MB for GIS 
means, that the software is rather strange, because how detailed a map 
has to be to use such huge memory? For a comparision, a raw 1024x1024 
bitmap with 24bit color depth and 8bit alpha occupies only 4MB...

Why caching is so important? Because of what you say about the access to 
GIS data. Our consideration on speed of rendering are really not 
important when compared with the cost of access to GIS data. Here are 
real bottlenecks eg mass storage or RDBM access. One has to use spatial 
indeces and queries here, but usually it is not enough because RDBMS 
servers are always too slow, and network bandwidth is always too low. 
Caching can moderate such cost, but obviously requires some additional 
RAM :-).

Nevertheless, I really appreciate your post and agree with many thesis, 
in particular with that rendering is not as important as proper GIS data 
management :-)

Best regards
Marek Brudka