Best way to animate elements passing through viewport in infinite loop - javascript

I have a set of elements, set next to each each in a row. The number, scale, etc of these is dynamic. I would like them to pass from one side to the other on the screen in an infinite loop, so as one element leaves the one side it comes in again on the opposite, like this:
Here is a Codepen Illustrating the above example. Imagine the black box is the viewport, so you can't see outside of it.
What is the easiest way to implement this conveyor belt/treadmill approach?
I've tried several ways of implementing this but am stuck finding a reliable, smooth, and flexible solution to what seems like a very simple problem. I've hit a wall, how would you do this?
I'm just looking for the concept, library, etc.
Could a GreenSock library work well for this?
If this is too ambiguous could anyone point me toward a more appropriate place to ask?
Thanks.

I don't know what makes you say it "seems like a very simple problem", because (for me) it clearly isn't. Let's break it down:
Make the conveyor belt move (I'm assuming you move the belt container for this).
Trigger whenever an element completely left the screen.
Move that element in DOM at the other end of the belt and simultaneously adjust the belt position so the change in DOM is not visible in the belt animation, which should remain smooth.
This is how I'd go for it, but there are chances that the animation might stagger/flicker when the change in DOM is made, especially if you have other animations running in the page at the same time. If this happens, you might want to clone elements instead of moving them and only delete the originals after the rendering of the clone is finished. It might "seem" (sic) like the same thing, but the browser will do them one after the other instead of in the same time. It sometimes helps.
I'm a curious guy by nature so I'm already planning on making a fiddle with this at the end of the day. If I find anything notable or if I come up with another approach I'll update.

Related

Moving a DOM node and browser repaint performance

Say I have a page with a bunch of divs stack one after another. At one point, I move the 30th one from its position below up to position, say, 5. This causes the old nodes 5 to 29 to move down a slot.
Neglecting what's inside the divs, how much of a relative performance impact does this operation have? If I understood the repaint concept correctly, this would cause a big repaint since lots of visible items' positions are changed. But I thought something as simple would have been optimized by the browser using some tricks.
Disclaimer: I did try to test the repaint on Chrome, but I guess my method wasn't adequate enough, and I couldn't discern much.
Here's the follow-up question: say I move a few of these divs around. What would be better in terms of performance: moving each individually, or, say, just simply re-append every node? My thought is that, at a certain point, would it be better to just re-append the whole thing once, rather than moving 6 or 7 divs around and repaint around half the screen each time (if that's indeed the case).
Thanks.
I read through this article a while back and it taught me a fair bit:
http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/
eg:
"
Apply animations to elements that are position fixed or absolute. They don’t affect other elements layout, so they will only cause a repaint rather than a full reflow. This is much less costly"
There's loads more useful tips there aswell.

Web Design: Client wants a rotation-based navigation bar

I don't know if this is possible, but the client is adamant. He wants his navigation bar contents to be aligned along a "Fibonacci Spiral".
This thing:
I don't even think the CSS3 rotation aspect is functional in any browser currently, and I have no clue if any of the scripting languages would allow me even the faintest of possibilities to create a custom, curving track to force objects to follow instead of the standard (and pretty much only) horizontal and vertical alignment methods. However, I truly do embrace a good challenge. Backing down without an effort is hardly doing a good job.
If any of you know any possibility even of the greatest magnitude in how I might achieve this effect, I would be amazed. THank you for your time! If you think this is truly impossible to achieve in a current web browser, say so!
Interesting idea anyways. Hope you can make your client happy.
I thought i might chip in with something.
Found a jQuery-plugin that bends text along a curve:
http://tympanus.net/Development/Arctext/
Perhaps one could make a layout of square divs of diminishing size and specify a curve for each one?
Possible div-layout if you turn it around: http://upload.wikimedia.org/wikipedia/commons/9/95/FibonacciBlocks.svg
The plugin specifies the curving from a radius-value and can curve upwards or downwards. It does not seem to be constructed for tilted curves, but that can perhaps be modified.
EDIT: I experimented a bit with the plugin, and i believe it certainly is possible to achieve the effect you need, albeit one does have to know trigonometry quite well (as far as i can tell) to make it function properly.
Another option, and the easiest way i can think of so far, is to make use of an old classic: Image map!
http://en.wikipedia.org/wiki/Image_map
Just photoshop a nice spiral image however you like and use image mapping to set linkable areas. This can maybe be of interest: http://www.outsharked.com/imagemapster/default.aspx?demos.html

When to use requestAnimationFrame?

Having discovered requestAnimationFrame just a moment ago, I have dived into all the information I could find about it. To name just a few of the resources I came across in case there are others looking for more info about it:
http://creativejs.com/resources/requestanimationframe/ - explains the basics about it.
http://www.html5rocks.com/en/tutorials/speed/animations/ - explains how to use it.
Anyway, all of these resources tell me something about how requestAnimationFrame works or how it could/should be used, but none of them tell me when it is right to use it.
Should I use it for animations (repeated changes to the style of an element, much like CSS animations)?
Should I use it when an automated event wants to change the css/classes of one or multiple elements?
Should I use it when an automated event wants to change the text value of one or multiple elements? (e.g. updating the value of a clock once every second)
Should I use it when an automated event wants to modify the DOM?
Should I use it when an automated event needs values like .offsetTop, .offsetLeft and then wants to change styles such as top and left a few lines further?
Should I use it when a user generated event causes any of the above changes?
TL;DR: When is it right to use requestAnimationFrame?
You shouldn't yet. Not really, at least. This is still experimental and may or may not reach full recommendation (it is still a working draft at this point). That said, if you don't care about older browsers, or willing to work with the polyfill available the best time to use it is when you are looking to draw things to the screen that will require the browser to repaint (most animations).
For many simple modifications of the DOM, this method is overkill. This only becomes useful when you are doing animations when you will be drawing or moving items quickly and need to make sure that the browser repainting is keeping up enough to make it smooth. It will allow you to ensure that every frame you calculate will be drawn to the screen. It also provides a utility for more accurate time measurements to your animations. The first argument is the time at which the paint will occur, so you can ensure that you are where you should be at that moment.
You should not use it when you are doing many simple modifications to the DOM, or things that don't need to be smoothly transitioned. This will be more expensive on your users' computers so you want to limit this to making things smoother in transitions, movements and animations. Forcing a frame redraw is not needed every time you make a change on the page, since the response will be fast enough most of the time you don't need to worry about that extra couple milliseconds between draws.
As the previous answer says, you should not use it in the discontinuous animation because that don't need to be smoothly transitioned. In most cases, it's used for properties which vary continuously with time.

Javascript component for window/pane flip effect?

I'm prototyping a thin client UI using extjs and am looking for an effect that will simulate a form/pane flipping over to reveal another form/pane. Its for a details view for an object that has two major sets of properties.
I found a flex component that can do this, and can even simulate four different forms on the faces of a cube.
Just a sexier, more fun way of doing what you can already do with tabs.
This particular effect may not be available on a cross-browser basis quite yet. Doing perspective transforms on a given DOM element is only possible in two ways that I know of:
1) Renderer-specific extensions, like Webkit's -webkit-transform
2) Rendering the DOM element inside of a Canvas element and then doing transforms on that
The problem with #1 is that it's clearly not going to be cross-browser. The problem with #2 is that you'd more or less have to write your own complete markup renderer for canvas to really get everything in an arbitrary DOM element in there.
(OTOH, I wouldn't put it past some ambitious and clever JavaScript ninja to have attempted #2, so though I haven't seen it yet, I wouldn't be totally surprised if someone else can point towards something like it...)
I would stick with the tab solution if you want to get your project done within a reasonable time. This does not exist for ExtJS - the one in Flex does a 3D effect. The only solution close is to just have content in 4 cells of a table that slides into view (according to the direction of the arrow you used), within a DIV, and have the overflow property set to hide, so you can mask out the other cells and show one cell at a time. Then use the animation (fx) functions to slide the content in and out of view, perhaps with some arrows you hover over or click.

slider that also magnifies around cursor

It can be difficult to use (webpage) sliders that cover a large range with fine granularity. On the one hand, it is easy to move across the range. On the other hand, it is difficult to locate the exact point one wants, assuming a fine enough granularity.
I was thinking that a magnify effect around the cursor could solve this problem (assuming the problem really exists).
I looked for existing solutions or ideas via google, but couldn't find anything.
Any suggestions here?
I doubt if this is what you're looking for, but... within Mac OSX, holding down the control key and moving the scroll wheel will zoom in and out.
I'm having trouble thinking of a scenario where having so much data that scrolling of this nature would be a problem you'd want to have. In almost all scenarios it makes more sense to chunk up the data or reduce it down in some other way.
About the only thing that makes sense is the seek-bar/scrubber on a video player. If your player is 400px wide with a 360px wide scrubber, but the video is an hour long, the best granularity you'll get is 10 seconds-per-step (with the step-size being 1 pixel).
If that isn't enough granularity, then it's possible you'll need to augment your scrubber with another UI convention - which could be a magnifier - but it could also be other things. Like a "jump to point" text field that would allow to user to entire a time and seek to that exact position.
It sounds like you're going for something (visually) like the OS X dock. This is called a fish-eye effect. There's a jQuery plugin for a fish eye menu which you may be able adapt and merge with a slider to give you the functionality that you're looking for.

Categories

Resources