search

usgs-makerspace / makerspace-sandbox

Some initial R code for playing with data processing (maybe some light visualization).
Other
0 stars 5 forks source link

SVG tooltip saga #604

Closed lindsayplatt closed 4 years ago

lindsayplatt commented 4 years ago

From @collnell:

At the end of Friday last week we hit some obstacles to implementing the cartogram in vue. To be able to make it interactive with the tooltip it needs to be coded using inline svg, which is causing performance issues due to the size of the file

lindsayplatt commented 4 years ago

First - what does the top SVG map do? It has working hovers and tooltips. Are those inline?

Second - @jread-usgs and I are working on coding up the SVG to not have a rectangle built for every single bar in every state. That should probably decrease the overall SVG size by a lot and may make it possible to do the inline tooltip approach without performance issues.

jordansread commented 4 years ago

I can help weigh in on this if that would be useful. Perhaps a quick video meeting today?

cnell-usgs commented 4 years ago

Yes, the top svg map uses inline svg as well. While we are able to insert the svg using the separate file we (myself and @abriggs-usgs ) could not get the tooltip to work in that way. To mimic the initial chart we attempted to implement using inline svg which seemed appropriate for the interactivity but this caused performance issues. With a different implementation for the tooltip this may work, we think the file size would need to be ~1/4 of what it currently is for optimal performance.

jordansread commented 4 years ago

I assume Lindsay's new file will be way smaller. Instead of each state/terr/DC having 130 <rect/>, it will have one. So 6.7k fewer lines in the svg.

lindsayplatt commented 4 years ago

Please see https://github.com/usgs-makerspace/gages-through-the-ages/pull/159

jordansread commented 4 years ago

Seems tips aren't working on the cartogram for Firefox image

They do work for the top SVG (the animated one). Seems let translate_elements = window.getComputedStyle(evt.target.parentElement).transform; isn't working and this gets "none" in FF

A different way of getting style works:

evt.target.parentElement.getAttribute('transform')
"translate(372.045 175.84)"

but the format of that is different

lindsayplatt commented 4 years ago

Ok, that's a bummer about Firefox. Are you saying that the format of the result of evt.target.parentElement.getAttribute('transform') is different from the getComputedStyle method? If so, should be easy to change the string handling commands in subsequent lines. I can work on this fix if you would like.

jordansread commented 4 years ago

Yes, the result of the getAttribute is (I think) just the exact string in the transform. So it could be something like translate(1,4)scale(1.5,5) or translate(1 4)scale(1.5 5), which makes it a little harder to make assumptions for parsing it. But since you are automating the code that creates the transform, there is less worry that those string formats might change...your solution was more robust and better, but the FF issue throws a bit of a wrench in it.

lindsayplatt commented 4 years ago

Right. And a quick Google shows that FF does indeed have a reported bug with getComputedStyle. The reported bug is from 2012, so I don't think we can rely on it being fixed 😉

See the section called "More on getComputedStyle" here: https://stackoverflow.com/a/32296604

lindsayplatt commented 4 years ago

Fixed that last issue in https://github.com/usgs-makerspace/gages-through-the-ages/pull/172