Open everbeek opened 10 years ago
It appears that in IE (but not Firefox or Chrome), that svg:polylines may not be nested in svg:g elements. I cannot find it documented, but the lines get positioned properly when I drag them out of the svg:g elements int he console view. This is sheer lunacy. Figuring something out.
Oh, my dear, dear Internet Explorer. This bug seems to be known, and is labeled "Won't Fix".
https://connect.microsoft.com/IE/feedback/details/781964/
To summarize, it looks to me that the bug is based on lame handlign of SVG markers in IE. Observe it not working, then working, int he fiddles below:
No work: http://jsfiddle.net/niaconis/3YsWY/ http://jsfiddle.net/niaconis/3YsWY/1/ Work: http://jsfiddle.net/niaconis/3YsWY/8/ http://jsfiddle.net/niaconis/3YsWY/9/
These cases made it work by first removing markers (unfortunate), then by faking them with more complicated paths (really not a substitute).
So...I have to decide which solution I like. After verifying that removing markers fixes this problem. It is likely the case, because when I pulled the lines out of the svg:g containers, I was also un-nesting them from the marker definition.
Oh, yes, deleting the marker definitions makes all the arcs snap to position. Ok, I am changing this ticket's definition, and setting the visualization to not include marker definitions when IE is run.
In issue #377, I mention pre-rendered glyphs. Is this an option too?
The markers became broken in Firefox as well recently. I have reimplemented as two separate SVG elements, no SVG markers present. This has affected performance on very large graphs, from what I can see (such as the concept expansion of artery in: http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=term_neighborhood&ontology_acronym=UBERON&full_concept_id=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FUBERON_0006591&restURLPrefix=data.bioontology.org
In any case, IE, Firefox and Chrome all have nice markers, styled as solid lines, inheriting color from the arc. Right now only inheritance and composition have markers, but they can be added to mapping and property relation arcs.
Actually, the inefficiency above appears to be during loading of the concept expansion, not of rendering. When I drag things around or trigger layouts, it seems perfectly adequate.
For future reference, this would improve performance, I believe: http://stackoverflow.com/questions/1422238/svg-about-using-defs-and-use-with-variable-text-values
The key is defining a single instance of each arc head, using the <use. directive, and also wrapping in a
http://support.microsoft.com/kb/3003057 Check the GDR fixes http://support.microsoft.com/kb/3012779
Microsoft fixed this. We were also looking for a workaround and thank god we could save some performance hit with this :)
Thanks for the heads-up Praveen. I will have to look into going back to the marker implementations I had before, if the issue I observed with Firefox has also been resolved.
Used to be titled "Node-Edge Disconnect in IE". Discovered that marker definitions (or just markers generally) are to supported in what appears to be any version of IE. They recognize it as a bug, and it has a "Won't Fix" status. Changing this issue to be about replacing markers with another implementation, at least for IE, such as faking them with additional polyline segments.
http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=term_neighborhood&ontology_acronym=SNOMEDCT&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FSNOMEDCT%2F35146001
The nodes and edges are fully disconnected. Clearly I am doing something to identify nodes or arcs that IE doesn't support.