Re: [GRASS-dev] xganim: fix compilation or remove completely?
Vaclav Petras wrote: The only question is if wxpyimgview is as fast as wximgview. Speed is the only reason why they exists, isn't it? Not really. A fundamental property of those programs is that they will dynamically update the display whenever the image file changes. For display commands which take a while to execute, updates can continue during the drawing process. This was a significant reason for supporting memory-mapped images: once the file has been created, it remains valid even while being modified. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] xganim: fix compilation or remove completely?
On Sun, Dec 22, 2013 at 11:34 AM, Glynn Clements gl...@gclements.plus.com wrote: Vaclav Petras wrote: The only question is if wxpyimgview is as fast as wximgview. Speed is the only reason why they exists, isn't it? Not really. A fundamental property of those programs is that they will dynamically update the display whenever the image file changes. For display commands which take a while to execute, updates can continue during the drawing process. This was a significant reason for supporting memory-mapped images: once the file has been created, it remains valid even while being modified. Naive question: is this technology also used for the wx0 etc monitor which is rather slow? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] xganim: fix compilation or remove completely?
Vaclav Petras wrote: xganim removed in r58484 and r58487. Do we want to keep wximgview (I believe that it has been superseded by wximgview.py)? If not, we can remove the wxWidgets configure checks altogether. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] xganim: fix compilation or remove completely?
On Fri, Dec 20, 2013 at 10:26 AM, Glynn Clements gl...@gclements.plus.comwrote: Vaclav Petras wrote: xganim removed in r58484 and r58487. Do we want to keep wximgview (I believe that it has been superseded by wximgview.py)? If not, we can remove the wxWidgets configure checks altogether. Good point, we have now: ximgview (visualization/ximgview/) wximgview (visualization/wximgview/) wxpyimgview (scripts/wxpyimgview/) For sure, we don't need all three and wximgview is C++ and wxWidgets (so it does not fit to our C+Python+wxPython). The only question is if wxpyimgview is as fast as wximgview. Speed is the only reason why they exists, isn't it? I'm wondering if somebody is using at least one of them. Vaclav -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] xganim: fix compilation or remove completely?
Hi, when testing the previous problems with C++11/clang/Mavericks, I used the following compilation settings on Ubuntu 12.04: export CC=clang export CXX=clang++ export CFLAGS=-ggdb -Wall -Wextra -Werror-implicit-function-declaration -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls export CXXFLAGS=-ggdb -std=c++11 I get the following errors in `visualization/xganim` directory: ./bitmaps/rewind.xbm:4:28: error: constant expression evaluates to 128 which cannot be narrowed to type 'char' 0x00, 0x00, 0x00, 0x30, 0x80, 0x01, 0x28, 0x40, 0x01, 0x30, 0xa0, 0x01, ^~~~ ./bitmaps/rewind.xbm:4:28: note: override this message by inserting an explicit cast 0x00, 0x00, 0x00, 0x30, 0x80, 0x01, 0x28, 0x40, 0x01, 0x30, 0xa0, 0x01, ^~~~ stat)c_castchar( and a lot of other similar errors. I'm not getting these errors on Mavericks. I'm not able to test the xganim tool [1] right now; there is no ready-to-use example and I'm not sure which environment it requires (I'm getting white window bigger than my screen). However, the question is: It is worth keeping the xganim tool in code or should we remove it completely? Are there any functions which xganim tool does have comparing to g.gui.animation [2]? Or are there some other advantages of xganim? We should avoid loosing functionality as it was with tools such as gm_animate [3]. So these questions shall be answered before removing xganim. Best, Vaclav [1] http://grass.osgeo.org/grass70/manuals/xganim.html [2] http://grass.osgeo.org/grass70/manuals/g.gui.animation.html [3] http://grass.osgeo.org/grass64/manuals/gm_animate.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] xganim: fix compilation or remove completely?
Vasek, I think that if there are no objections xganim can be removed from grass7, the new animation tool is much, much better. It may be worth keeping it in grass6.4*. To test xganim just use any output from r.sim.water or r.sun.daily or nags head series. If you are seeing window larger than your screen check your region settings - the size of the xganim window in pixels is the size of your region (so either change the region to lower resolution or smaller spatial extent). We can go through xganim in the lab (I may have it still running on the mac laptop) to make sure we have everything in the new animation tool that was in xganim, but I believe that we do, Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” On Dec 11, 2013, at 10:38 PM, Vaclav Petras wrote: Hi, when testing the previous problems with C++11/clang/Mavericks, I used the following compilation settings on Ubuntu 12.04: export CC=clang export CXX=clang++ export CFLAGS=-ggdb -Wall -Wextra -Werror-implicit-function-declaration -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls export CXXFLAGS=-ggdb -std=c++11 I get the following errors in `visualization/xganim` directory: ./bitmaps/rewind.xbm:4:28: error: constant expression evaluates to 128 which cannot be narrowed to type 'char' 0x00, 0x00, 0x00, 0x30, 0x80, 0x01, 0x28, 0x40, 0x01, 0x30, 0xa0, 0x01, ^~~~ ./bitmaps/rewind.xbm:4:28: note: override this message by inserting an explicit cast 0x00, 0x00, 0x00, 0x30, 0x80, 0x01, 0x28, 0x40, 0x01, 0x30, 0xa0, 0x01, ^~~~ stat)c_castchar( and a lot of other similar errors. I'm not getting these errors on Mavericks. I'm not able to test the xganim tool [1] right now; there is no ready-to-use example and I'm not sure which environment it requires (I'm getting white window bigger than my screen). However, the question is: It is worth keeping the xganim tool in code or should we remove it completely? Are there any functions which xganim tool does have comparing to g.gui.animation [2]? Or are there some other advantages of xganim? We should avoid loosing functionality as it was with tools such as gm_animate [3]. So these questions shall be answered before removing xganim. Best, Vaclav [1] http://grass.osgeo.org/grass70/manuals/xganim.html [2] http://grass.osgeo.org/grass70/manuals/g.gui.animation.html [3] http://grass.osgeo.org/grass64/manuals/gm_animate.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
