[GRASS-dev] xganim: fix compilation or remove completely?

GRASS GIS GRASS GIS developer
1

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_cast(

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

2

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
hmitaso@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_cast<char>(

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

3

There are no features in xganim which g.gui.animation does not have. The same applies to gm_animate.

The only exception is accepting wildcard expression instead of map name which is than expanded into the list of map names but this is not problem which this tool should be solving. In GUI you can use regular expressions to input multiple maps or time series and in command line, there is the g.mlist module.

xganim removed in r58484 and r58487.

Vaclav

[r58484] https://trac.osgeo.org/grass/changeset/58484

[r58487] https://trac.osgeo.org/grass/changeset/58487

···

On Wed, Dec 11, 2013 at 10:55 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

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
hmitaso@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_cast(

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

4

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 <glynn@gclements.plus.com>

5

On Fri, Dec 20, 2013 at 10:26 AM, Glynn Clements
<glynn@gclements.plus.com>wrote:

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 <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

6

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 <glynn@gclements.plus.com>

7

On Sun, Dec 22, 2013 at 11:34 AM, Glynn Clements
<glynn@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