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.
Related
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.
I have a strange problem with Google maps and it is happening with all the 3.X versions I tried. When I am panning the map the new tiles do not load, when I zoom (in/out - does not matter) - they load as expected. If I leave the page alone the missing tiles start loading after a very long delay - over a minute. I used Fiddler to check if there are any hanging requests - I found none - when sent they return quickly, so there is no networking problem involved. I noticed also that the standard controls (the zoom control) load with the same delay as well. This is happening in both IE and Chrome, I decided there is no point in trying it in other browsers - it is obviously something common.
Everything else works - I am showing lines and polygons, even editing them and reading back the edited vertices, however this affects also things like markers and I am receiving a DOM exception for them (with the same long delay).
Unfortunately it will be very difficult to pass any source code along. I am using the maps in a very complex windowing plus data binding javascript environment and I blame it for the issue, but all the diagnostics I have made show no problem anywhere. I debugged the application and there is not even a trace of a problem, delays cannot be caused by the environment (It is my work, so I know it from top to bottom) and the only possibility for a mix up I can imagine lies in some methods I am attaching to the Function object - otherwise there is no spot where the both can possibly collide. The strangest thing is the delay - if it broke I'd probably have already found it.
Any similar problems, anyone? Even a description of the problem under different circumstances may prove helpful I suppose. I searched for any similar issues, but found nothing of the sort.
I've been updating a Node.JS FFI to SDL to use SDL2. (https://github.com/Freezerburn/node-sdl/tree/sdl2) And so far, it's been going well and I can successfully render 1600+ colored textures without too much issue. However, I just started running into an issue that I cannot seem to figure out, and does not seem to have anything to do with the FFI, GC, speed of Javascript, etc.
The problem is that when I call SDL_RenderPresent with VSYNC enabled, occasionally, every few seconds, this call will take 20-30 or more milliseconds to complete. And it looks like this is happening 2-3 times in a row. This causes a very brief, but noticeable, visual hitch in whatever is moving on the screen. The rest of the time, this call will take the normal amount of time to display whatever was drawn to the screen at the correct time to be synced up with the screen, and everything looks very smooth.
You can see this in action if you clone the repository mentioned above. Build it with node-gyp, then just run test.js. (I can embed the test code into StackOverflow, but I figured it would be easier to just have the full example on GitHub) Requires SDL2, SDL2_ttf, SDL2_image to be in /Library/Frameworks. (this is still in development, so there's nothing fancy put together for finding SDL2 automatically, or having the required code in the repository, or pulled from somewhere, etc.)
EDIT: This should likely go under the gamedev StackExchange site. Don't know if it can be moved/link or not.
Doing some more research online, I've discovered what the "problem" was. This was something I'd never really encountered before, (somehow) so I thought it was some obvious problem where I was not using SDL correctly.
Turns out, graphics being "jittery" is a problem every game can/does face, and there are common ways to get around it. Basically, the problem is that a CPU cannot run every process/thread in the OS completely in parallel. Sometimes a process has to be paused in order to run something else. When this happens during a frame update, it can cause that frame to take up to twice as long as normal to actually be pushed to the screen. This is where the jitter comes from. It became most obvious that this was the problem after reading a Unity question about a similar jitter, where a commenter pointed out that running something such as the Activity Monitor on OS X will cause the jitter to happen regularly, every couple seconds. About the same amount of time between when the Activity Monitor polls all the running processes for information. Killing the Activity Monitor caused the jitter to be much less regular.
So there is no real way to guarantee that your code will be run every 16 milliseconds on the dot, and that it will always ever be another 16 milliseconds before your code gets run again. You have to separate the timing for code that handles events, movement, AI, etc. from the timing for when a new frame will be rendered in order to get a perfectly smooth experience. This generally means that you will run all your logic fewer times per second than you will be drawing frames, and then predicting where every object will be in between actual updates, and draw the object in that spot. See deWiTTERS game loop article for some more concrete details on this, on top of a fantastic overview of game loops in general.
Note that this prediction method of delivering a smooth game experience does not come without problems. The main one being that if you are displaying an object in a predicted location without actually doing the full collision detection on it, that object could very easily clip into other objects for a few frames. In the pong clone I am writing to test the SDL bindings, with the predicted object drawing, if I hold right while up against a wall the paddle will repeatedly clip into the wall before popping back out as location is predicted to be further than it is allowed. This is a separate problem that has to be dealt with in a different way. I am just letting the reader know of this problem.
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.
I have looked at a lot of Q/A here on SO regarding similar (if not the same) question I have. Yet none had an answer I was able to understand.
I wish to input a series of GPS coordinates, and create a smooth curve that connects them all, and passes through ALL of them. Javascript is my preferred language and I have found this page
http://jsdraw2d.jsfiction.com/demo/curvesbezier.htm
It allows you to plot any number of points and when clicking the 'Draw Curve' button it does exactly what I want (except it is on html5 canvas whereas I want to use lat/lon values)
You can download the jsDraw2D source code here:
http://jsdraw2d.jsfiction.com/download.htm
The function in question is drawCurve() and it appears to calculate the points of the curve, creating a separate 'div' for each point as it goes along, while also appending them to the html page. I am presuming I need to get rid of the code for creating the html divs and instead add each point as it is calculated to an array or string. However, it is simply over my head (perhaps because it seems overwhelming and my understanding is not quite spot on).
I would post the code here, but it is pretty long, plus I am not sure how many other functions it calls/requires from the rest of the script.
The only other thing I can think of that needs to be considered is the +/- values in GPS coordinates. I am hoping that altitude changes would not effect the smooth line created too much, especially since it seems to create the new points so close together.
Any help in modifying that code would be greatly appreciated. If someone has some other approach, I am open to suggestions - however I would prefer a way that passes through ALL the input points (unlike some mathematical curve functions that do not)
Thanks!