Develop Reference

How could I improve performance when repeatedly updating an SVG DOM in React JS?

Last year I tried to learn a bit React JS for making the project you can find here. I apologize for my rather vague / imprecise description below, but I'm by no means versed in this.
Basically, there is a single <svg> tag, which will contain a number of paths etc. as created by the user. The problem I have is that things become very slow the more paths are present. To my current understanding, this is due to the fact that the entire SVG DOM gets updated repeatedly upon user interactions that involve dragging the mouse or using the mouse wheel.
This holds true, particularly, for two user interactions:
a) Panning - all paths are being moved at the same time; I think one might circumvent this issue by taking a snapshot image first and moving that around instead. However, that's not a solution for the other user interaction, which is:
b) Expanding/collapsing paths - here, all paths are being modified in terms of coordinates of some of their points. That is, every path must be modified in a different way, but all of them must be modified at once, and this must happen repeatedly because it's a user interaction controlled with the mouse wheel where changes happen gradually and the user requires immediate visual feedback on these changes as they happen.
Particularly for b), I see no alternative that would involve a single transformation or something.
After extensive research last year, I came to the conclusion that choosing SVG to display and modify a lot of things dynamically on screen was a wrong decision in the first place, but I realized too late, so I gave up and have never touched it since. I'm pretty certain that there isn't any way to deal with the low performance that builds upon what I already have; I have no intention to start this project from scratch with a completely different approach. Also, the reason why I chose SVG was that it's easy to manipulate.
In summary, I'd basically like to get confirmation that there is no feasible way to rescue this project.

Timetable events packing

I'm working on timetable for school purposes. I receive time-ordered list of events and my goal is to draw them on timeline. The problem is that some event overlaps another (as shown on the picture below). What I want to do is to "pack" this events into the smallest space possible. This is single day with overlapping events.
First picture shows what I managed to do so far. As seen on picture, rectangles do not intersect each other and fill free space nicely. BUT I didn't manage to come up with reasonable algorithm for ordering.Second picture shows how events should be ordered.
This are two conditions, which make this problem different from classic packing problem:
Events has given x-coordinates (defined by beginning and end).
Events has fixed width, height is arbitrary.

This Problem reminds me a little bit of file system fragmentation problem. Easy solutions would be to implement one of the famous algorithm e.g. first-fit or best-fit.
But I guess you want the best solution. That's why I'd suggest implementing a backtracking algorithm. Be aware that I can cause long runtimes but I think this doesn't really matter in your context.

vis.js physics - how to fix some nodes in place

In my application, a graph is loaded initially with the one-net of a particular node. The user can expand the graph by double-clicking any node to add its one-net.
The problem is that every time the user does that, the nodes all jump around, so it's confusing. I don't want to just disable physics, because then the new nodes get jumbled on top of the old ones. For lack of a better explanation, I want to freeze the existing nodes, only using physics to arrange the new nodes (and then freeze them before adding more). I looked at Stop vis.js physics after nodes load but allow drag-able nodes, but that doesn't solve my problem.
I'm pretty clueless about what the various options to the physics solving algorithms mean, and can't find a good description anywhere, so I wonder if there may be tweaks there that would help me.
Thanks!

You can give some of your nodes a fixed x and y position. There are also methods like getPositions() and storePositions() to retrieve or set the positions after the first stabilization or something like that.

Increase zoom speed when using GoJS

I did some research on this topic here, on the GoJS documentation site, etc., but I am not able to find anything coming even near to what I want.
Here's the thing: I have a diagram written in GoJS. As the data behind it is fairly big, it happens to be fairly large. So I was wondering if there was any possibility to increase the zoom speed built into GoJS, so that with one scrollstep more scale was added.
What i tried until now is doubling the
scrollHorizontalLineChange:
scrollVerticalLineChange:
both to 32.
No difference to before so far. Or is there any of the many tools GoJS has, to allow me this sweet increase when needed?
Theoretically, it is possible to use the "ViewportBoundsChanged" event to change the zoom factor when it's triggered. But would this be a good solution?
Thanks in advance.
Oh and if any additional details are needed, I will be happy to provide them.

Set CommandHandler.zoomFactor, http://gojs.net/latest/api/symbols/CommandHandler.html#zoomFactor :
$(go.Diagram, ...,
{ "commandHandler.zoomFactor": 1.2 },
...)
The ToolManager handles mouse events when no specific Tool is running, and it calls Tool.standardMouseWheel, which calls CommandHandler.increaseZoom or CommandHandler.decreaseZoom as appropriate.
By the way, Diagram.scrollVerticalLineChange controls how far the diagram is scrolled when you click on the scrollbar's up button or down button. Or when you call http://gojs.net/latest/api/symbols/Diagram.html#scroll

Structuring an HTML5 Canvas/JS Game

I'm new to HTML5/Canvas/Game programming, but have been tinkering around with it after reading a couple of books. I THINK I have a fairly good idea of how things work out. This question asks several smaller questions, but in general is basically a "structural approach" question. I'm not expecting verbose responses, but hopefully small pointers here and there :) Here is a link to a non-scrolling, and currently rather boring Super Mario World.
Super Mario World Test
NOTE: Controls are Left/Right and Spacebar to jump. This is only setup for Firefox right now as I'm just learning.
Did I Do Something Wrong at This Point?
Currently I've just focused on how Mario runs and jumps, and think that I've gotten it down fairly okay. The coin box doesn't do anything and the background is just an image loaded in for looks. Here's my approach, please let me know if there is anything entirely wrong with this:
Allows Mario to jump by enacting on 2 Y velocities (Gravity and Jump variables)
Allows Mario to run by enacting on 1 velocity (Left or Right "Friction" + Acceleration)
Sprites are used and positioned according to keypress/keydown
I'm not sure if this is right, but I'm using a constructor function to build an object, then inside the main animation loop I'm calling the prototype.draw function for that object to update all variables and redraw the object.
I'm clearing the entire canvas each Frame
Should I be splitting this into more than just a draw function, like Mario.move()?
I've setup a GroundLevel and a JumpLevel variable to create 2 planes of gameplay. The JumpLevel is setup to allow for controlling how high Mario can jump on the fly. The 2 places would allow for the ground to rise like a hill - keeping the point at which Gravity overrules Mario's jumping force at the same distance from the ground.
For clarity sake, everything is separated into different JS files, but would obviously consolidate.
Moving Forward:
Now that I've finished setting up how Mario moves around (I think there are a couple other minor things I might do like mushroom up/down and shooting fireballs). I think I can figure that out, but I'm really lost when it comes to visualizing the following and how HTML5/Canvas can handle this easily:
Scrolling background (I've tried setting up Ground Tiles and using Screen Wrapping, but that seems to cause a lot of uneven issues since I was moving the tiles in the opposite direction. Unfortunately, since I'm trying to account for acceleration, this threw off the count and was causing gaps in the ground. I ditched this idea. Would a DIV beneath the canvas with a large background image be the best solution?
Enemies: Would I create enemies the same way and run a loop for collision detection on every enemy during each frame?
Background Boxes: I'm trying to allow Mario to stand on the boxes in the background, but am unsure how to approach this. I currently have boundaries setup for Mario to stay on the canvas, do I continue to expand these conditions to setup different boundaries based on the boxes? I can see that having several boxes on the screen and doing it this way would get kind of crazy, especially if I would be doing the same hit testing for enemies? I know I'm missing something here....
Level Movement: This is somewhat related. When the Right key is pressed, basically everything in the level needs to move to the left. Would I need to track out all positions of everything that could touch Mario (boxes for him to stand on and enemies for him to collide with) during every animation frame? This seems like it would get kind of inefficient?
Thanks to all! I'll keep this updated with results/solutions :)

Wow, okay. I really like your question because you've obviously done a lot of thinking on this, but partially because of that it's incredibly broad and conversational. You'd do better to find a forum to ask this question.
...That being said, I'm gonna answer the handful of points I'm qualified to, in no particular order. :)
Level Movement: That's a weird (read: inefficient) way to do it. I wouldn't do any calculations based on onscreen positions: track a canonical, camera-agnostic set of coordinates for everything in your level and update the visuals to match. This will stop you from running into weird niggling problems where framerate impacts what you can and can't walk through, or causing slower computers to let Mario run through enemies without being damaged sometimes. Tracking positions this way will incidentally fix a lot of your other problems.
You should absolutely be splitting this into multiple functions. Having movement code and rendering code in the same place is going to screw you, particularly by interacting malignantly with your update/refresh rate. It's going to essentially mean that every time the player does a tricky jump the game does more updates than usual which will make animation/hit detection/etc much less likely to be even.
Enemies: I'd suggest rolling this in with everything else. Do one hit-detection pass against everything, and if you hit something check to see what it was. You could try to optimize this by only checking any given entity against objects within 100 pixels of itself, but if you do it this way you'll need to run separate collision detection events for every enemy. Letting the enemies clip through each other would be computationally cheaper.
Edit: I'd like to clarify about my first point on 'level movement.' Essentially, what you don't want to do is move every entity onscreen every time the camera does, or to store all entity locations as offsets from the camera location (in which case you're still effectively having to move everything, every time the camera moves.)
Your ideal approach is to store your enemy, block, terrain locations with X/Y coordinates that are offset from the absolute top-left of the level (at the very beginning.) In order to render a frame, you'd do essentially this: (pseudocode because we're talking about a hypothetical level format!)
function GetVisible(x,width,level_entities_array) {
for (i = 0; i < count(level_array); i++){
if (level_entities_array[i][x] > x && level_entities_array[i][x] < x+width) {
visible_elements[] = level_entities_array[i][x];
}
}
return visible_elements;
}
Boom, you've got everything that should be inside the window. Now you subtract the camera's x offset from the entity's x location and ZAP, you've got its position on the canvas. Pose as a team, 'cause things just got real.
You'll note that I'm not bothering to cull on the Y axis. This can be rectified by extrapolation, which I'm guessing you can handle because you've made it this far. This will be necessary if you want to do any Mario-style vertical exploration.
Yes, I know my pseudocode looks like C# and JavaScript's unholy lovechild. I'm sorry, that's just how I roll at 11:30 at night. ;)