[BUG-6767] Perspective Disappearing Pipes in Perspective Clients

v8.1.21
Browser (Chrome)

I'm finding that Perspective Pipes (using the piping tool) disappear randomly.

e.g.
image

What it should be:
image

It's not possible to predict when it's going to remove pipes in the client. I though it was resolution-based, but if I go into full screen, out again, and back in, sometimes the pipes disappear, other times they don't for the same page.

@mperkins
This is a big issue for operators

Just a shot in the dark, but do you maybe have a background element and something setting z-index on it or the pipes?

Nope! Just a super simple page with a bunch of embedded views (devices) and some pipes. Well, the example screenshot above isn't as simple, but I have the same issue on pages with a handful of embedded views and <5 pipes

Did you check if the the pipes still exists in the html (but are just displaced/invisible)?

Yep, pipes are all there, just not being rendered

The top 4 are not rendered, the bottom one is.

Interestingly, I put another application window over the top of the browser and then moved it away, and the pipes rendered... only in Chrome, sometimes. Edge still stays invisible

It seems there are some hacky resolutions in other apps as well, like Matlab...

image

However, I set all my coords in the SVG line to integer values in chrome dev tools, and still it doesn't render

This still doesn't render:

<g class="ia_pipe ia_pipeIsolate">
<line class="ia_pipeSegment--pid" mask="url(#C-0-mask-4_0-4)" x1="10" y1="80" x2="726" y2="229" style="stroke: var(--neutral-50); stroke-width: 5;"></line>
<polygon class="ia_pipeSegmentNode--pid" mask="url(#C-0-mask-4_0-4)" points="726,77 721,87 731,87 " stroke-width="0" style="fill: var(--neutral-50);"></polygon>
</g>

Well, this "fixes" it (for fast-loading pages)... but breaks other things, like my soul

could you post the code here instead of a screen shot^^

do any of the embedded views also have pipes? My hunch is there is some sort of id collision occurring with the masking- ie mask="url(#C-0-mask-0-4)" that # id might exist in multiple embedded views. I'm looking into it now.

if you don't mind running code from me in the Chrome's Developer console on an affected view... this will identify duplicate id's for you

const idMap = new Map();
document
    .querySelectorAll("*")
    .forEach(
        (element) => {
            const { id } = element;
            id && idMap.set(id, (idMap.get(id) ?? 0) + 1)
        }
    );
for (const [id, count] of idMap.entries()) {
 count > 1 && console.log(`#${id} occurs ${count} times`)   
}

You'll get something like this:
Capture

and I can tell if those id's pertain to piping or not

1 Like

Results:

const idMap = new Map();
document
    .querySelectorAll("*")
    .forEach(
        (element) => {
            const { id } = element;
            id && idMap.set(id, (idMap.get(id) ?? 0) + 1)
        }
    );
for (const [id, count] of idMap.entries()) {
 count > 1 && console.log(`#${id} occurs ${count} times`)   
}
VM1061:11 #ac_unit occurs 4 times
VM1061:11 #tank-fermenting-outline occurs 3 times
VM1061:11 #warning occurs 29 times
VM1061:11 #keyboard_arrow_left occurs 7 times
VM1061:11 #keyboard_arrow_right occurs 8 times
VM1061:11 #coordinateGhost occurs 87 times
VM1061:11 #build occurs 31 times
VM1061:11 #lock occurs 29 times
VM1061:11 #refresh occurs 3 times
VM1061:11 #pan_tool occurs 25 times
VM1061:11 #check occurs 14 times
VM1061:11 #security occurs 12 times
VM1061:11 #water-sharp occurs 2 times
VM1061:11 #construction occurs 2 times
VM1061:11 #gateway occurs 2 times
VM1061:11 #path-1 occurs 2 times
VM1061:11 #done occurs 2 times
false

I wouldn't have thought there would be any duplicates though as the pipe do show up when you resize the browser

If they are the same views inside the embbeded contaienrs then it shouldnt matter if their are identical id's. They all will refer to only one def (first probably).

Feel free to pm me a copy of the html/views if you want me to take a look

Thanks for doing that, none of the duplicate id's listed would cause the issue, though resizing the browser to cause it to render does give me a clue. I'll investigate further and get back with my findings.

I still haven't been able to reproduce it locally, but I have something new for you to try.

Would you copy and paste this Button component somewhere in your view and press the button when the Pipes aren't showing?

The button has an onClick mouse event, it increments session.props.pipes.overlapGap by some small number (.000000001) . This forces the pipes to rerender, helping me to diagnose whether it's the pipe's themselves that aren't rendering properly, or if it's something else like the dimensions causing the issue.

[
  {
    "type": "ia.input.button",
    "version": 0,
    "props": {
      "text": "Press to rerender"
    },
    "meta": {
      "name": "Button"
    },
    "position": {
      "x": 0.5813,
      "y": 0.3424,
      "width": 0.0584,
      "height": 0.0518
    },
    "custom": {},
    "events": {
      "dom": {
        "onClick": {
          "type": "script",
          "scope": "G",
          "config": {
            "script": "\tself.session.props.pipes.overlapGap += .000000001\n"
          }
        }
      }
    }
  }
]

I'll test this today, but would changing the appearance achieve the same thing? Eg from p&id to something else back to p&id. This is what my work around script is doing at the moment. Changing the gap would would less intrusive though!

but would changing the appearance achieve the same thing?

yes, they both result in the pipes rerendering

good that there's a non-intrusive work around, I'll continue attempting to reproduce the issue and log a bug when I do

btw why does the svg have style:" width:0px; height:0px" ?

that's actually a very good clue - it's not @nminchin 's doing, it's the Pipe Renderer. "under the covers" the PipeRenderer sets a width and a height for the SVG based on the contents of the SVG that is being generated, there is likely a bug in that code.

I haven't nailed down the exact cause yet, but I'll file a bug for further exploration

3 Likes