I am implementing Cytoscape.js web 2.0. I am a bit confused on the difference between load and add. I understand that in load, we do not need to specific the positions of the nodes. I used add to add a node which works when I include the position attribute, but the edges do not show even when I add the position attribute. Also, what is the difference between load and add behind the scenes? I believe that load renders the entire graph, so every time we use load, it would re render the graph. It seems that add does not do that which is good for operational costs? Is that true?
Thanks!
Putting cy.add() outside of the object right after the full object is initialized allowed adding nodes to update the graph.
cy.load() is used to load a new graph and run a layout on that graph. This is deprecated in newer versions of 2.x and it's not available in 3.x! Run a layout after calling cy.add() if you want this kind of behaviour.
cy.add() is used to just add elements to the existing graph.
Related
After rendering or some other actions, I want to read the target image into cpu.
For this, there is need first to do layout transition and change the image's current layout (old layout ) to a new one that allows transferring its data into stage image - VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL.
For transition operation, I need to give both, the current layout and the new layout.
But how do I know what is the current layout ? - each render pass may set the finalLayout to a different value, it also may that some transitions where done by the time.
A solution I think is to store per image its current layout and set it after each render pass , and after each transition operation.
Is this correct?
But how do I know what is the current layout ? - each render pass may set the finalLayout to a different value, it also may that some transitions where done by the time.
Yes, but you created those render passes. You issued commands to use those render passes on that image. Therefore, at any point in the command stream, you know what layout the image is in.
Vulkan expects you to be aware of what you've done. How you pull that off is up to you. Maybe you always leave the image in color-attachment optimal. Maybe you explicitly keep track of it with some higher-level layer. It could be any number of things.
But at the end of the day, it's up to you. With great power, comes great responsibility.
I'm making an isometric city builder using Monogame Extended and Tiled. I've got everything set-up and now i need to somehow access the specific tiles so i can change them at runtime as the user clicks on a tile to build an object. The problem is, i can't seem to find a "map.GetLayer("Layername").GetTile(x,y) or .SetTile(x,y) function or something similar.
Now what i can do is edit the xml(.tmx) file which has a matrix in it that represents the map and it's drawn tiles. The problem with this is that i need to build the map in the content pipeline again after editing for the changes to be displayed. I can't really build at runtime or can i?
Thanks in advance!
Something like this will get you part way there.
var tileLayer = map.GetLayer<TiledMapTileLayer>("layername");
TiledMapTile tile;
if(tileLayer.TryGetTile(x, y, out tile))
{
// do something with tile
}
However, there's only a limited amount of things you can actually do with the tile once you've got it from the map.
There's no such thing as a SetTile method because changing tile data at runtime is not currently supported. This is a limitation of the renderer, which has been optimized for rendering very large maps by building static geometry that can't be changed once it's loaded into the graphics card.
There has been some discussion about building another renderer that would handle dynamic map changes but at this stage nothing like that has been implemented in the library. You could always have a go at implementing a simple renderer yourself, a really basic one is not as hard as you might think.
An alternative approach to dealing with this kind of problem might be to pre-process the map data before giving it to the renderer. The idea would be to effectively separate the layers of the map that are static from those that are dynamic and render the dynamic tiles as normal sprites. Just a thought, I'm not sure about the details of how this might work.
I plan to eventually revisit the Tiled API in the next major version of MonoGame.Extended. Don't hold your breath, these things can take a lot of time, but I am paying attention to the feedback and kinds of problems people are experiencing with the existing API.
Since the map data is stored in a XML (or csv) file which runs through the Content Pipeline you can not change it at runtime.
Anyways, in a city builder you usually do not change existing tiles but you place object on top of existing tiles.
The 10.2.7 runtime has the class 'AttributeLabelClass' that allows you to format the labels for graphics and add it to a GraphicsLayer such that all Graphics with a certain attribute will render the same way.
Does anyone know if anything like this survived into the 100.0+ timeframe? I've been looking all over for this with no luck (which usually means it's right in front of my nose).
I'm fairly sure something like this exists because I've seen prototype demos of their efforts to resolve label confliction rendering issues.
We're hoping to have this feature back in Update 1. The public API might not be fully complete by then, but you'll at least be able to set everything with the json definition, and a more full-blown API for all the properties by Update 2.
I have created elements with outPorts in bottom or top part. My requirement is to create an element which have outPorts in top and bottom parts.
Is it possible?
Since JointJS v1.0 there are many pre-defined port layouts. Including Bottom/top positions. It comes also with a new port API where ports can be added to any shape easily (joint.shapes.devs.Model is not needed anymore).
demo:
http://resources.jointjs.com/docs/jointjs/v1.0/demo/layout/Port/port.html
doc:
http://resources.jointjs.com/docs/jointjs/v1.0/joint.html#layout.Port
I am building a reactjs application, I have two options for rendering the components
One is hiding the component and appending the other component on top
of it with the same space and different layout.
The other option is re-render and re-create DOM for both the components
separately.
React uses diff algorithm to compare and change the states of the DOM, as the component is already present in the DOM so the first solution may work faster. But it will have more amount of in-memory data than the second solution.
On the other hand in the second solution, we have to remove the DOM of one component, render the other component and create the DOM for it again. That looks like a lot of work!
I am confused, which approach should I follow?
This can be depicted as:
<Component1/>
<Component2/>
Solution 1: Hide <Component1/> and Append <Component2/> in the same space.
Solution 2: Remove <Componen1/> and Append <Component2/> in the same space
You are prematurely optimizing. You've probably already spent more engineering time on this problem than it is worth. Option 2 is simpler to implement, simpler to reason about, and is the happy path when working with React.
If, after you've built it, you feel it is performing too slowly, then you should do some performance profiling and find the bottlenecks. Don't worry about Option 1 until, and only if, this profiling suggests that the recreation of the DOM elements is the bottleneck.