I am using Cytoscape.js 2.7.15 for my graduation project and i need to make some simple visualizations like changing the labels of nodes.
subjectNode.style('label',myDesiredLabelToshow);
works for me but i am using it in a for loop and when i want to make it slowly or in debug mode to see how my algorithms works to label them, the labels of nodes do not change immediately, they change eventually together after my function ends (i mean hit to end scope of function).
I tried to use cy.batch(); cy.startBatch() even tried to set Timeout but nothing worked.
After tracking cytoscape.js file in debug mode i saw a function o.requestAnimationFrame = function.. after debugger hits that changes are applied on my graph, how can i manually trigger it in my custom functions?
Pretty much any renderer is going to use a render loop using requestAnimationFrame(). That means it's async, and you won't see results while stepping.
The answer is not to use breakpoints or stepping, because those methods assume everything works synchronously.
Use a button in your UI to "step" through points in your algorithm, or use animations in a promise chain to visualise progression. Or forgo showing debugging cues in the UI itself and just use console.log().
Related
I am using Jupyter notebook to run a large-ish program in steps. As part of the code - in order to get the graphs that I am plotting to be visible in non-scrolling windows - I am using:
%%javascript
IPython.OutputArea.prototype._should_scroll = function(lines) {
return false;
}
Which I originally found on stackoverflow.
I am also using:
plt.rcParams["figure.figsize"] = [16,12]
(matplotlib.pyplot as plt, as usual) in order to control the size of the output plots.
The data is read in and the code loops through it. In the section doing the plotting (all inside one loop) it is producing a number of plots at the right size, with the correct annotations, and then it will suddenly and apparently produce a valid diagram but reduced to postage stamp size. It will do this for a few plots - and then revert to normal size and then do the same thing again.
The above is the only code I am using to explicitly control plot sizes and both sit outside the loop. Inside the loop - and each time it is executed - there are multiple calls to plt routines.
It's almost as if the parameters in plt.rcParams are being over-written but since they are outside the loop, they shouldn't be shouldn't they?
Any thoughts on why this is happening? -and of course how to fix it. Can overplotting (which I am doing on some plots) have something to do with it? Should the javascript be modified?
Many thanks
OK, the more I look at it and try to create a MRE (see comments above), the more I come to the conclusion that the issue is something in the way that I am passing "stuff" between the calling routines and the library. As such it is an idiosyncracy of my code/system and probably not of wider interest. If something of general interst comes up I will post it here or in an appropriate spot.
========================================================================
That was my initial response last month, however having looked into this much further it appears not to be an issue with passing between the libraries and the calling program, as it also occurs in programs that don't call the libraries. It appears to be something in the way that rcParams interacts with Jupyter notebook as configured on my machine (which is a fairly basic configuration).
I am unable to take thisd further at the present time.
I'm building real time time layout.
If server sends packages every 200ms, then Function Call + Recalculate Style + Layout + Paint time must be less than 200ms.
By using performance.mark with performance.measure or just console.time('1') with console.timeEnd('1') i can measure Function Call what is not enough.
Is there any known way how to put some sort of anchors to get and log number that includes Paint?
That will be used for automated performance testing.
Thanks in advance!
It isn't possible to log Paint times using the Console API. It looks as though there was an attempt to integrate this into WebKit several years ago, but this never got implemented. Right now, you can only do CPU profiling using console.profile, but this isn't relevant for you.
You need to explicitly run the Timeline tool to gather Paint profiling data. You could look into using macros to run this. You can export your data into a JSON file, so that you can re-import and compare each one. It's not optimal for automated testing, but I'm not sure of other ways.
This isn't going to include the paint time itself, but requestAnimationFrame will be called just before the paint.
I also tried setTimeout(fn, 0), but it turned out to be called fairly long after the paint.
If all you want to know is that there is some time left at the end of a frame you might be able to use requestIdleCallback.
From looking at the code, it seems that three does not give much control over the depthFunc. I would like to confirm that it's only set once as the default GL state, and not available say, in the material?
I'm not familiar with all examples, and was wondering if this is happening somewhere?
If not, what would be the best approach to set the depthFunc to gl.EQUAL for example, when a specific draw call is being made i.e. a mesh with a material?
Is something like toggling between scenes i.e. use one to render stuff, then use another one to render stuff on top of the first one a good solution for this? That's the only example that i've seen of tweaking the otherwise sorted objects.
It's currently in the dev branch of three.js: the pull request.
I'm using box2dweb version 2.1.a.3 (javascript, ported from flash), to create game. Some examples that I've got from Google used:
setInterval(
function(){
world.Step(1/60 , 10, 10)
world.ClearForces()
}
,1000/60)
I tried to remove the line world.ClearForces() but things behaved the same. I wonder what function ClearForces() does? What trouble can I get if I remove it like that ? Thanks!
I can't say for sure about the Flash and Javascript versions, but the ClearForces function was originally necessary in early versions of Box2D. Back then if you did ApplyForce to move an object, that force would remain in effect indefinitely, but now you need to do ApplyForce every time step if you want a continuous force. So effectively, the engine is calling this ClearForces for you every step. If you can take it out without changing anything you might as well.
I do have a Paper.path() in Raphael that is filled with a simple texture:
var fill = screen.path(Iso.topFacePath(top)).attr({
fill: 'url(http://www.example.com/mytexture.jpg)',
});
The path can be altered by the user via drag and drop. For this I use Element.drag() to bind the handlers.
The problem that I encouter now is that while the onmove-handler function is called the element in question will be recalculated and has to be drawn again. Apparently this is "too much" for raphael and the fill pattern will disappear randomly (flicker) and appear again some time later (at latest onend).
The actual code I use is a little too much to post here but I built a fiddle where you can see what's going on (you can drag the upper sides of the quadrangle).
Is there a simple fix to this?
I am used to canvas much more than raphael (actually this is the first time I really use raphael) so maybe my approach of redrawing everything everytime sth changes is plain wrong?
EDIT: I just found out that seems to be somehow browser-related as well. Chrome and Firefox will produce the flicker where Safari seems to do everything just fine.
This seems to be caching issue (raphael.js does not cache the bitmap fill and will reload it on every change) and is fixed (for me) by this pull request on GitHub that is (as of 08/14/2012) still pending.
Raphael is pretty hard / impossible to build oneself as the make file points to local and/or inexistent files, but you can either concatenate everything by hand, modify the build script or use the modified build that is used in the example to get hold of the fix.
Let's hope it will find its way into a future release of Raphael.