New to using Adobe Edge, though very familiar with Flash/AS. I need to do animation sequence that is not flash-based, so trying out Adobe Edge. The animation itself is all done, everything works correctly. However, when the JS is loaded on the site and viewed (at least in Chrome/FF) when an object is easing out it creates black bars behind it - looks like it's skidding to a halt.
These disappear when anything is moved - background, any div, anything layered on top, etc. Can handle with setInterval flashing a transparent div on top of it, but seems a bit of a ridiculous way to solve. Has anybody else run into this? Is there a setting I'm missing?
Figured this out after ton of testing, etc. Basically the way Adobe Edge works - at least at this point - is that if you put the animation on top of something else, the background color will "leak" through the animation and show up as skid mark looking lines. After playing with every setting in their UI, nothing would handle. Final work around was to put a background image behind the animation that matched, so when it showed through it wasn't detectable.
Related
Call me crazy, but I'm working on a game using vanilla DOM and TypeScript. It's not action-heavy, but there are some animations going on, which are driven from JavaScript (too complex to do in CSS).
I'm already applying the common trick of translateZ(0) (called null transform hack or less accurately silver bullet) to pull animated elements into their own rendering layer, and I'm animating nothing besides compositor-only properties (transform and opacity). This works beautifully: during the game, everything feels buttery smooth, even on older mobile devices.
The problem is during the start of the game. At that moment, about 70 individually transformed and animated elements enter the page one by one over the space of a few seconds, by animating their opacity from 0 to nonzero. This is causing visible stutter during the animation.
My guess was that Chrome is being too clever here, and will only rasterize each element at the moment it first becomes visible. A quick check with the dev tools confirms this, as there's a lot of rasterization going on even during the animation:
I would prefer to rasterize all these elements once, before the animation starts, and only then trigger the animation. But how can I force rasterization of elements that aren't yet visible, without showing a flash of them to the user?
I'd be happy with a Chrome-only approach, but cross-browser would be even better.
I'm new to the HTML\CSS\Javascript thing, so please excuse my incompetence. I know for some bits (mainly class modification) I'm not using jQuery, but only because I couldn't get it to work, so I went old-skool.
I have a web page (here: http://dashboards.kantarhealthspain.com/uk/segmentation/Segmentation_v0.4.html) that works just fine in Chrome (and Safari) on my desktop. You click on the massive squares in the middle of the page, and then click on the >> to go to the next 'page'. Eventually you get to the point where it hides\unhides one of 4 segments based on what you've chosen. It's a bit clunky, but it works, which right now is a win...
When I view the same page on an iPad, the layout isn't quite as good, but that's not my problem. When you get to the final question to show\hide the segments, it seems to change the way the whole page is rendered - every element seems to take up so much room.
Debugging on an iPad is very difficult, as I'm using a Windows machine to develop, and the Safari emulator doesn't actually emulate what's going on, as it doesn't break on desktop Safari (for Windows).
I don't even know where to start looking on this - any hints would be much appreciated.
EDIT: Now I've fixed the evil HTML, it looks like when the divs at the bottom are shown\hidden, the height of each div above doubles(?) I've made the background of NavDiv and Breaker fuschia and maroon so they show up, and the double in size. The height is a percentage of the size of the page (I presume) - what's going on there?! Does the percentage recalculate when areas are unhidden?
Thanks
Tom
I have an issue with jQuery ScrollTo.
It skips and there is a lag when applied to my page.
Here's a link to the jsFiddle example that works and here is the same code applied to my page that does not work.
It might function correctly on some machines but all the machines I have tested this on don't!
Might there be an issue with the amount of images I am using?
Is there anything I can do to overcome this?
The problem there is the background image. On "poor peformances machines", using a full page background image like you did and scrolling is not very efficient.
For instance, my machine at work lags as hell on your page, either using the top menu or regular scrollbar. On the otherhand, my MacBook Pro handles your page perfectly with a smooth feel when using the top menu to scroll.
I tested it using chrome on my machine, and removing the background image using developers tools. It now works perfectly. As soon as I put the background image back, it starts lagging again.
Its a bit jumpy on my machine (your site that is), but one thing i noticed that may help is that it is really nice and smooth smooth if i very quickly click back and fourth between 'Senior Executive' and 'Experienced Hire'.
Is there any callback or some calculation being done before, during or after the scroll perhaps?
I have a container div that holds about 20 more divs that float left. When I resize the parent div with a javascript animation using Tween.js the floats don't reflow to the new size unless I mouse over one of the divs.
It seems like something is preventing the page from refreshing.
I'm thinking maybe there is a way through javascript to force the display to update?
UPDATE:
I've put it on JS Fiddle:
http://jsfiddle.net/mattlundstrom/fNUhn/
Click any thumbnail to toggle the animation.
This version uses TweenLite to animate the "Left" CSS of the #project-container. Notice how you must move your mouse after the animation to get the container's contents to reflow.
I get this result in Safari 5+ OSX and Chrome 20+ OSX. Works as expected in Firefox 13.0 OSX.
UPDATE 2
Video of what I'm seeing:
http://f.cl.ly/items/1R1n2s0U3I3c1M3s2K0T/lundstrom_float_issue.mov
I was able to recreate your issue just as you said. It seems that it is an issue with webkit redrawing or measuring the elements after an animation or transition.
This isn't the best solution by any means, but for the time being at least it will work and hopefully what I found will help other people to be able to find out more.
If you add an onComplete to the animation, and trigger the .project mouseleave, it looks to work fine:
function completeAnimate(){
$('.project').trigger('mouseleave');
}
function contract(){
// PROJECTS CONTRACT RIGHT
TweenLite.to($('#projects-container'), .5, {css:{left:"300px", opacity:".5"}, ease:Expo.easeInOut, onComplete: completeAnimate});
}
So here is my jsfiddle which has a few tests and other animation tests so that you can see some of what I tried.
jQuery animate() and css keyframe animations have the same result as the Tween code you are using, HOWEVER, a straight style update works fine.
$('#projects-container').css('left','300px');
No issues with that at all, but of course, no animation either.
Some other things I noticed was that if you take out the .project event bindings, it still doesn't redraw correctly, however if you move you mouse it still doesn't. It simply stays that way.
I also tried forcing an element redraw using a few tricks you can usually use to force a redraw. I tried this oncomplete and at intervals after the animation begins, but had no luck with any of it.
You can also combine the two tweens into one with the properties on both, just an FYI.
Hopefully this will help someone find the true issue that's going on with the webkit transitions.
Im using JavaScript, the HTML5 canvas-element and WebGL to make a simple 3D-game in first person view for fun.
Ideally, I would like to control my movement by using the keyboard to move and the mouse to look around, like you usually do in FPS-games. As you probably understand, there are some limits to this in the browser, since the mouse cant be captured:
When using the onmousemove event, no further movement will be detected when the mouse pointer reaches the border of my screen (which means that I wont be able to run in a circle for example)
Seeing the mouse move across the screen is not the end of the world, but it is a little annoying
From what I know, it's impossible to hide the mouse as well as setting it's position in JavaScript. Hence, my question is this:
If we cant to those things, what can we do in order to get close to the desktop gaming experience when it comes to the mouse in the browser?
And I mean right now, using current APIs. Not "what could be changed in some standard to make life easier". Also, I realize that I could use the keyboard to look around, but then we're back in 1995 when Quake were actually played like that. And of course I know that it would be easier to write a desktop application or use Flash at least, but Im trying to push JavaScript's limits here.
Apart from those things, what are your suggestions? Any kind of reference, existing game, crazy idea, hack or even browser specific solution would be appreciated.
I have done some experiments with mousehiding for a game, as far as I recall it was only Opera that I didn't make behave, so I gave it the cross instead. One crucial point is that some browsers will display a completely invisible cursor image as a black box, but with just one almost invisible pixel it'll work. Feel free to take the mousehiding part and the cursor file. http://ebusiness.hopto.org/iimdtdt/
I have thought a bit about the look around part myself, for the up/down movement it is easy, since you will cap this anyway, and all you have to do is to make sure that the cap is in sync with the mouse movement cap. For the sideways part, I suggest that you try messing with the sensitivity, when the mouse nears the edge of the screen sensitivity should go up it the direction towards the screen edge, and down in the direction away from the screen edge. I haven't tried out this method, so I can't tell how well it will actually work, but it should help keep the mouse in the middle area even if the user spins around more one way than the other.
Good luck with the project, sounds exciting.
Your hopes and dreams are now possible with the new Pointer Lock API