I am using cytoscape.js version 2.0.3 for creating graph. I have noticed a problem that sometimes entire canvas drawn by cytoscape.js becomes black and after few seconds, it recovers. This problem occurs when some event (e.g., 'tap', 'cxttap') occurs, especially for large graph. What should I do to avoid it? Please help.
Related
Presently I'm learning the basics of real-time raytracing with the DXR API in DirectX 12 Ultimate. I'm studying the D3D12 raytracing samples on the official GitHub and am using an i9/Intel Iris Xe/RTX3070 laptop and building the programs in VS2022.
Since the samples were written for Windows 10 and I'm using a hybrid graphics PC, a Debug build will run in Windows 11 after adding D3D12_MESSAGE_ID_RESOURCE_BARRIER_MISMATCHING_COMMAND_LIST_TYPE to D3D12_INFO_QUEUE_FILTER during device creation (see DirectX 12 application is crashing in Windows 11). The only trouble is that none of the sample programs change to fullscreen (i.e. borderless windowed) mode when pressing the Alt+Enter key combination. The programs always stay in windowed mode.
This hasn't worried me so far, because I've been copying the raytracing code over to a template (based on DirectX Tool Kit for Windows desktop) where fullscreen toggling works properly. In this way, I was able to run the HelloWorld and SimpleLighting samples successfully in both windowed mode and fullscreen (2560x1440 monitor resolution).
However, this hasn't been so successful for the ProceduralGeometry sample, which introduces intersection shaders. Once again, the original sample program renders the scene properly, but only in a bordered window. But when the code is reproduced in the template where I can toggle to fullscreen, the raytraced scene does not render properly.
In the scene, the triangle geometry used for the ground plane of the scene renders ok, but a translucent bounding box around the fractal pyramid is visible, and all other procedural geometry also appears translucent. Every couple of seconds, the bounding box for the metaballs also appears briefly, then vanishes.
I was able to determine that by freezing the scene, the reason for the translucency was that the following frames were being presented in sequence:
triangle ground plane quad only
floor geometry plus opaque fractal pyramid bounding box
all of the above plus opaque metaball bounding box
completed scene with opaque geometry and no bounding boxes
At the native framerate (165Hz on my machine), this results in both the procedural geometry and bounding boxes always being visible, but 'see-through' due to all the partially complete frames being presented to the display. This happens in both windowed and fullscreen modes, but it's worse in fullscreen, because the scene gets affected by random image corruption not seen in windowed mode.
I've been grappling with this issue for a few days and can't work out the problem. The only changes I've made to the sample program are the Windows 11 fix, and using a template for proper fullscreen rendering, which the original sample ignores or doesn't implement properly.
Hopefully someone can shed light on this perplexing issue!
I found the problem. Each sample has a header file called DXSampleHelper.h. For the ProceduralGeometry sample, this header file was updated with a helper class to manage structured buffers, which is very similar to the helper class for constant buffers.
The CopyStagingToGpu() method, which consists of a one line memcpy operation in both classes, is slightly different for the structured buffer class:
memcpy(m_mappedBuffers + instanceIndex * NumElementsPerInstance(), &m_staging[0], InstanceSize());
The same method in the constant buffer class is:
memcpy(m_mappedBuffers + instanceIndex, &m_staging[0], InstanceSize());
I.e. I was missing instanceIndex * NumElementsPerInstance() and thus the procedural geometry instances within the structured buffer were not correctly aligned in GPU memory.
I am rendering graphs of hundreds of nodes, in a directed manner from left to right.
Upon first render, all nodes are in the upper left, and then animate over two seconds to fill my svg box. (fit: true, animate: true, animationDuration: 2000).
One thing I notice is that while expanding, the graph is temporarily larger than my svg box, until it snaps into place. It also appears that the "snapping into place", while still smoothly animated, goes "faster" than the initial animation, even if I have easing set to linear.
But I also have functionality that allows me to (cxtmenu) select a node from the graph, and graph from that node. The rest of the nodes disappear, and then that subgraph animates into place to fill the svg box.
However, the closer to the lower right that node at the root of that subgraph is, the odder the behavior is. If I pick a subgraph close to the lower right, then while it is zooming in, it actually travels further to the lower right at first, even to the point of going entirely off the graph, until it finally zooms (more quickly) back into place in the center of the svg box.
Conceptually, it feels like this has to do with the initial positioning of the subgraph's root node, since it is not at 0,0. It's almost as if the layout algorithm starts first, and then at some point partway through, the fitting/panning algorithm kicks in at a faster rate.
I am having trouble determining how to control/fix this. On an earlier project with dagre and d3 (without cytoscape), I found that similar behavior was because of two competing animation algorithms; one for the layout and one for the zoom/positioning. When I set them to the same duration, they canceled each other out and the animation became smooth.
I am using cytoscape-elkjs. I did try out cytoscape-dagre, and its "boundingbox" option did seem to help, but the elkjs extension doesn't have that, and I am wondering if there's something I can do on the cytoscapejs level to control this.
So I've been giving Cytoscape a try recently. My project's goal is basically a collaborative graph that people will be able to add/remove nodes to/from, making it grow in the process. The graph will include many compound nodes.
Most of the examples I've seen use container div that takes 100% of the screen space. This is fine for "controlled" graphs but won't work in my case because its size is intended to be dynamic.
Here's a JSFiddle using the circle layout within a fixed 3000px/3000px container:
https://jsfiddle.net/Jeto143/zj8ed82a/5/
Is there any way to have the container size be dynamic as opposed to stating it explicitly? Or do I have to compute the new optimal container size each time somehow, and then call cy.resize()?
edit: actually, using 100%/100% into cy.fit() might just work no matter how large the network is gonna be, so please ignore this question is this is the case.
Is there a recommended layout for displaying large/unknown amounts of data in a non-hierarchical way that would "smartly" place nodes (including compound ones) in the most efficient way possible, all the while avoiding any overlap? (I guess that's a lot to ask...)
Why doesn't cy.fit() seem to be working in my example? I'm using it both at graph initialization and when CTRL+clicking nodes (to show closed neighborhood), but it doesn't seem to like the 3000x3000px container (seems better with 100%x100%).
edit: also ignore this question if you ignored 1., as again it seems fine with 100%/100%.
Any help/suggestions would be greatly appreciated.
Thank you very much in advance.
TLDR: It's (1).
Cytoscape has a pannable viewport, like a map. You can define the dimensions of the viewport (div) in CSS. What's displayed in the viewport is a function of the positions of the nodes, the zoom level, and the pan level -- just like what is visible in a map's viewport is a function of zoom, pan, and positions of points of interest.
So either you have to
(a) rethink your UI in terms of zoom and pan and use those in-built facilities in Cytoscape, or
(b) disable zoom and pan in Cytoscape (probably stay at (0, 0) at zoom 1) and let the user scroll the page as you add content to the graph and resize its container div to accommodate the new content.
I've got a working cytoscape.js instance that looks like this:
I have been trying unsuccessfully to configure the graph so that the node labels don't overlap. The graph uses arbor for layout. Playing with the repulsion levels doesn't have much effect on the problem. Gravity (or lack thereof) doesn't either. Is this a layout issue or a cytoscape.js config issue and how do I fix it?
Secondarily, node shape is supposed to be a 40x40 ellipse, which it generally is. But when a node is grabbed, it displays as a rounded rectangle. Why?
I've created a gist with my javascript and some data. It's dependent on jQuery (~2.1), cytoscape.js (>=2.3.9) and arbor.js as provided in the cytoscape.js lib directory. And it needs <div id="cy"></div> for a target.
(1) Overlap is a function of layout. If changing layout parameters is unsuccessful for your usecase, a different layout is probably the solution.
(2) That's the overlay -- not the node's body.
I am having strange artifacts on a tiledmap while scrolling with the camera clamped on the player (who is a box2d-Body).
Before getting this issue i used the linear filter for the tiledmap which prevents those strange artifacts from happening but results in Texture bleeding (i loaded the tiledmap straight from a .tmx file without padding the tiles).
However now i am using the Nearest filter instead which gets rid of the bleeding but when scrolling the map (by walking the character with the cam clamped on him) it seams like a lot of pixel are flickering around. The flickering results can get better or worse depending on the cameras zoom value.
But when I use the "OrthoCamController" class from the libgdx-Utilities which allows to scroll the map by panning with the mouse/finger i don't get these artifacts at all.
I assume that the flickering might be caused by bad camera-position values received by the box2d-Body's position.
One more thing i should add here: The game instance runs in 1280*720 display mode while my gamecam renders only 800*480. Wen i change the gamecam's rendersolution to 1280*720 i don't get those artifacts but then the tiles are way too tiny.
Has anyone experienced this issue or knows how to fix that? :)
I had a similar problem with this, and found it was due to having too small a decimal value for the camera position.
I think what may be happening is some sort of rounding with certain tile columns/rows in the tilemap renderer.
I fixed this by rounding to a set accuracy, like so:
camera.position.x = Math.round(player.entity.getX() * scalePosition) / scalePosition;
Experiment with various values, but I got it working by using the tile size as the scalePosition value.
About tilesets, I posted a solution here: Getting gaps between tiled textures with libgdx
I've been using that method with Tiled itself. You will have to adjust "margin" and "spacing" when importing tilesets in Tiled to get the effect working.
It's 100% working for me :)