Image Rendering

Topics: General Topics, Web Controls, WinForms Controls
May 24, 2007 at 7:10 AM
Hi All, It will be a good idea to render the image asynchronously. So that the applicaiton window does not freeze and probably we can display a status bar with the indication of the rendering progress. Can I try to implement this using BackgroundWorker component provided by .NET Framework? If yes, please through some direction.
May 24, 2007 at 6:12 PM
I'm trying to implement such behaviour in the MapBox control, it's quite easy conceptually, but you must check carefully what happens while map is rendering... I'm modifying Renderers too to allow Rendering interruption (let's say you tried to render a map that simply is too detailed, and simply you want interrupt the process if it takes too long), which requires asynchronous behaviour.
One of the problems I encountered is what happens if you are still rendering the map and, in the meantime, you try to pan, or zoom... I think it's better to use simple threads to handle this problem, instead of BackGroundWorker, since you need far more control on the operation (thread Join, interruption etc)... Remember that you have to debug your code carefully, otherwise deadlocks and such could happen (obviusly only 1 thread at time has to access Map data ^^)
May 25, 2007 at 4:06 AM
I will disable functionalities as zoom and pan during that time. But I feel asynchronous process here may not speed up rendering but will give the user more control and better GUI.

Good luck with your trial and do keep us posted how it worked out?
May 25, 2007 at 5:11 PM
Well, indeed asynch rendering does not speedup the process itself (it depends on the geometry itself, so async rendering will NOT make the control faster at rendering), but it can speedup the zooming/panning without clipping the image, since you can show the current image, while creating in background a larger image used for pan/zoom operations (well, it's far more suited for pan operation, instead of dynamic zooming); moreover the stop rendering function can be far more useful than people could think (every good GIS provides such a functionalty, since you can't know everytime how large the layer to render is, so you must adjust the Min/MaxVisible properties 'on the fly' ^^).
Jun 4, 2007 at 10:15 AM
How is your effort going on this implementation? (I tried something but could not stop freezing the application.)
Jun 19, 2007 at 8:38 AM
This is being done in v2.0, where the rendering pipeline is redesigned. I tried to do it in the current development branch, but there were some limitations on the rendering pipeline architecture, so I decided to forego async rendering in 0.9 and 1.0.

Note that there are indeed numerous issues in doing this with GDI+. On the WinForm side, you have to know very well the threading model that Win32 imposes, and how to effectively offload work. Plus, in the end, it is a net minus for single proc boxes, as you mention, since both rendering and screen updates are CPU / GPU bound, and the resultant context switching will likely result in very jerky movements for large numbers of objects visible, both in the drawing and in the UI responsiveness. Multicore machines make this a bit better, but now you have two problems. In 2.0 we can get away with this because we abstract the drawing - we draw to paths, save the paths and then draw them during the single-threaded paint routine. The only thing we have to be careful of is concurrent access to the path cache.

On the WebForms side, you really shouldn't even be using GDI+. (1) Making a background thread do the work is putting you in a world of hurt, especially if you decide to grab a thread from the thread pool. I know you aren't talking about using this in WebForms, but no one should really even think about doing this unless they are precomputing vector paths from geometries and caching them for rapid access. But then, using GDI+. paths will probably crash your webapp. Sadly, however, there is no alternative for server-side drawing in the .Net framework. (2)

  1. Anyone ever read the docs for the System.Drawing namespace? "Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions."
  2. See this thread for a discussion about using GD.