In Web Browsers, globejs() ignores arcsLwd arguments

[DataStrategist]

Reproducible example:

d <- structure(list(origins = c("Afghanistan", "Afghanistan", "Afghanistan"), destinations = c("Germany", "Netherlands", "United Kingdom"), counts = c(40000, 100, 1), latitude.x = c(33.93911, 33.93911, 33.93911), longitude.x = c(67.709953, 67.709953, 67.709953), 
latitude.y = c(51.165691, 52.132633, 55.378051), longitude.y = c(10.451526,5.291266, -3.435973), colors = c("#E7298A", "#66A61E", "#E6AB02")), .Names = c("origins", "destinations", "counts", "latitude.x", 
                                                                                "longitude.x", "latitude.y", "longitude.y", "colors"), row.names = c(NA, 
                                                                                                                                                     -3L), class = c("tbl_df", "tbl", "data.frame"))
globejs(arcsLwd = d$counts, arcsHeight = .5,arcs = d[,4:7],
        arcsOpacity=.3,arcsColor = d$colors
        ,lat=d$latitude.x,lon=d$longitude.x,value=weights, color = "grey")

Plotting this in RStudio produces expected results:

But, if I view the same output in Chrome and Internet Explorer, the line width is ignored:

Am I doing something wrong? Or is there a preferred way of saving the globe?

Thanks for a great package!

[monteforest]

I'm having the same issues.

[bwlewis]

FYI sorry for the long latency, I am working on the threejs package this month. This will be fixed soon.

…

On 12/15/16, mportillo14 ***@***.***> wrote: I'm having the same issues. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #40 (comment)

[monteforest]

That's great! Looking forward to your update. Thanks!

[bwlewis]

A few things:

I can't reproduce this with either chromium or google chrome Version 55.0.2883.87 (64-bit).

However, I think I saw an issue in the code that could cause problems and changed that in 83c0de7

Try again using the GitHub version of the package and see if that last commit helps.

[DataStrategist]

Negative, still see the problem in Chrome Version 55.0.2883.87 m (Not sure if it's 64x version or not).

I tried installing the master... Was I supposed to install a specific branch?

[bwlewis]

Sorry for the latency. The master branch is right. I'm actually having trouble now with threejs on Linux and the globes in general...continuing to look in to this.

[bwlewis]

Can you try again with the master branch version 0.3.0 (about to go to CRAN)? I get:

with R version 3.4.0, threejs package version 0.3.0, Chromium browser version 58.0.3029.81 (on Ubuntu). I also tried on a Windows laptop with chrome and it worked OK.

[DataStrategist]

Sorry for the delay. I'm in mid-deliverable so I can't update to 3.4... but I just tried your latest version on R 3.3.1 and we're going backwards!

Shows nothing in Rstudio, and on Chrome, it doesn't show the line-width, nor does it show the white bar making the origin!

Latest Chrome and RStudio (1.0.143), and this is even a new laptop Windows 7Pro

Maybe some other users can try? I hate to delay your cran submission if I'm the only one w/ issues...

[bwlewis]

Thanks for checking this; this is super-important to fix so I'll to do so asap...

…

On 5/3/17, Amit Kohli ***@***.***> wrote: Sorry for the delay. I'm in mid-deliverable so I can't update to 3.4... but I just tried your latest version on R 3.3.1 and we're going backwards!  Shows nothing in Rstudio, and on Chrome, it doesn't show the line-width, nor does it show the white bar making the origin! Latest Chrome and RStudio (1.0.143), and this is even a new laptop Windows 7Pro Maybe some other users can try? I hate to delay your cran submission if I'm the only one w/ issues... -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #40 (comment)

[jimhester]

Can confirm this is still an issue, arcLwd seems to be ignored on Chrome on macOS, with both the current CRAN release and the current master. However if you use canvas rendering it does work as expected, so this seems only an issue with the WebGL rendering.

I would guess this bug is maybe due to upstream issues?