Changes between Version 3 and Version 4 of wxGUIDevelopment/MapRendering

Timestamp:

Apr 17, 2013, 3:22:29 AM (11 years ago)

Author:

wenzeslaus

Comment:

wximgview and other links

wxGUIDevelopment/MapRendering

@@ -3 +3 @@
 = Map rendering =
 
-''This page is about rendering in wxGUI. It contains proposals how to make it better. It it not about general map rendering in GRASS, however it may obviously interfere.''
+''This page is about rendering in wxGUI. It contains proposals how to make it better. Proposals can be incomplete but complete proposals are better. It it not about general map rendering in GRASS, however it may obviously interfere.''
 
 == Introduction ==
@@ -22 +22 @@
 
 Related discussion on mailing list:
- * [http://lists.osgeo.org/pipermail/grass-dev/2012-August/059099.html Speed map display in wxGUI on bigger monitors], ([http://osgeo-org.1560.x6.nabble.com/Speed-map-display-in-wxGUI-on-bigger-monitors-td4992997.html at Nabble])
+ * [http://lists.osgeo.org/pipermail/grass-dev/2012-August/059099.html Speed map display in wxGUI on bigger monitors] ([http://osgeo-org.1560.x6.nabble.com/Speed-map-display-in-wxGUI-on-bigger-monitors-td4992997.html at Nabble])
+ * [http://lists.osgeo.org/pipermail/grass-dev/2011-July/054947.html GRASS_RENDER_IMMEDIATE in GRASS7] ([http://osgeo-org.1560.x6.nabble.com/GRASS-RENDER-IMMEDIATE-in-GRASS7-td3995365.html at Nabble])
 
 Related changesets:
@@ -28 +29 @@
  * r54465 fix for not updating statusbar (possibly slowed down the rendering)
  * r52436 wxGUI: delete unused wx.Image instances when rendering
+ * r48040 show 'busy' mouse cursor while rendering
 
 
@@ -38 +40 @@
 About the last point, we are using rendering to files because displaying/drawing of maps is done by modules, not library functions (the functionality is in the library). Moreover, it is not safe to call GRASS library functions from GUI since they call `G_fatal_error()` which calls `exit()`, so on error the whole GUI ends (without an error because stderr is written into GUI console which ends too).
 
-== Currently used options ==
+== Currently used methods ==
 
  * wxGUI renders to uncompressed PPM and uses `g.pnmcomp`
@@ -52 +54 @@
   * Python loop was just so slow to be used
  * wxNVIZ uses OpenGL
-  * TODO: provide basic info here
+  * the rendering library is in C
+  * in wxPython GUI used through ctypes
+  * data are accessed through the standard GRASS GIS library functions (thus `G_fatal_error()` and `exit()` are there)
+  * TODO: provide more details if necessary, or delete this comment
+ * `ximgview` (C application which uses X)
+  * reads BMP images generated by PNG or cairo driver and uses `GRASS_PNG_MAPPED=TRUE` to get constant file size
+  * TODO: only documentation was used, provide more details from code, probably same as wxWidgets version
+ * `wximgview` (C++ application which uses wxWidgets)
+  * reads BMP images generated by PNG or cairo driver and uses `GRASS_PNG_MAPPED=TRUE` to get constant file size
+  * uses time to look to the file then read the file in for loop
 
 == Proposal: Do the composition in the wxGUI ==
@@ -142 +153 @@
 The idea of two different approaches for main GUI and monitors is not new. The current wxGUI (at least before r55230) uses different approach for layer rendering (the difference is the number of help files and the opacity handling).
 
-''(Sep 4, 2012, #1719)''
+''(#1719, 2012-06-04)''
 
 == Proposal: Directly access data with !NumPy ==
@@ -151 +162 @@
 
 ''This is just a brief of what I have. I can provide further details if anyone is interested. (rashadkm, 2013-03-29)''
+
+
+== Proposal: Use memory-mapped files or shared memory for output of `d.*` modules ==
+
+TODO: Comments not included because this requires further analyses anyway.
+
+''(ychemin, 2013-04-15)''