[Gdal-dev] GDAL & OpenEV / MFC

[Chapman, Martin]

Marek,
 
I hear ya, but I can render 3 millions points as filled polygons in 1 second in GDI+ on a mediocre machine (1.8mhz, 500 mb ram, and 48mb video card).
 
I was unable to get OpenGL that fast.  Although, it definitely could have been my code (which is usually the case) because one wrong call in a loop with a graphics library can kill your performance.
 
Martin

	-----Original Message----- 
	From: Marek Brudka [mailto:mbrudka at aster.pl] 
	Sent: Sun 1/16/2005 5:04 PM 
	To: Chapman, Martin 
	Cc: James Goodwin; gdal-dev at xserve.flids.com 
	Subject: Re: [Gdal-dev] GDAL & OpenEV / MFC
	
	

	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
	
	_______________________________________________
	Gdal-dev mailing list
	Gdal-dev at xserve.flids.com
	http://xserve.flids.com/mailman/listinfo/gdal-dev