We Keep Coding

Is there a way I can force chrome to do subpixel rendering for a slow translation?

Im doing a very slow transition of a background image (a view of space that slides slowly to the left). My problem is while it looks beautiful on Firefox, it looks horrible on Chrome. I get a "jittery" effect due to Chrome's lack of subpixel rendering, and the image just snaps to the next pixel. I cannot speed the image up because it will destroy the effect Im trying to achieve. I have tried using TranslateZ() tricks, I have tried every CSS3 effect I could think of to make it look better, Ive tried Kinetic.js, Ive even tried Babylon.js hoping that WebGL would fix my problem.
At this point Im at a loss and I might just have to give Chrome users a static background and cater more to the Firefox users in regards to the neat little things I can do for the UI UX, and then just put a disclaimer on my site saying that the page is best viewed in FF.
I REALLY dont want to do this. Is there ANY work around at all?

You can force subpixel rendering by applying a small transformation:
#container {
transform: rotate(-0.0000000001deg);
-webkit-transform: rotate(-0.0000000001deg);
}
But instead of using JS to make the animation work, why not use CSS3 animations?
If you use transform: translate() browsers will use subpixel-rendering by default.
Also since the performance is better you shouldn't get your jittery/wave motion.
More info on performance here: http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/
I've put together a simple demo here: http://jsfiddle.net/yrwA9/6/
(For the sake of simplicity I only used the -webkit- vendor prefixes)

CSS3 Flickering in Safari 6 on OSX (but this is not the flickering-to-white issue!)

This issue does not present on iOS or on Chrome so it is not a Webkit related issue. It seems to be specific to the latest Safari 6.0.2 on OS X 10.8.2 (and not fixed by 10.8.3 preview build 12D65 which comes with Safari 6.0.3). I shall test on Lion 10.7.5 with Safari 6.0.2 shortly, and will also be testing on preview build 12D68 as well.
http://jsfiddle.net/zrr2b/
Here is a fiddle that makes the problem quite apparent. If you've got a Mac running ML, you should see a significant difference between Chrome and Safari where Safari flickers a lot as you move the mouse around.
Basically the problem is that Safari will intermittently draw the target transform being set from JS for a single frame, then continue the transition animation. This causes a flicker, but only if the transition was in the middle of going somewhere to begin with. So the bug won't rear its ugly head for most (non intensive use) of CSS3 transition, but if functionality or visual effects depend on it to smoothly interpolate to a target (as my current project does) this flicker is not pleasant.
I have looked at similar topics related to flickering and applied pretty much all combinations of styles to counteract flickering, such as the -webkit-backface-visibility: hidden, forcing various parent elements to gain hardware acceleration, -webkit-transform-style: preserve-3d, -webkit-perspective: 1000, and none of them unfortunately do anything to address this Safari-specific problem of flickering, that is, flickering not to white or blank, but flickering to the target transform for a single frame.
Here in this branch you can see me set a bunch of styles that help with "regular flickering" but have no effect for me. http://jsfiddle.net/zrr2b/1/
As this is not a webkit specific issue I am unsure where to go about posting a bug report. It would be especially nice to get this in before 10.8.3 release since I see this as a rather big issue. Remember, this is the sort of thing that we're depending on HTML5 to do well in order for it to really kill Flash.
Updates:
Safari Version 6.0.3 (8536.28.10) on Mountain Lion 10.8.3 12D68 (Retina Macbook Pro 15.4") still suffers from this issue
Safari on Windows (5.1.7) does not suffer from this bug
Safari Version 6.0.2 (7536.26.17) on Lion 10.7.5 (Macbook Air Mid 2011) does not suffer from this bug

There are a few different ways of experimenting with reducing the flickering. The big problem however, it's that they seem to be "hit and miss". So you got to try a few to see which one helps resolve the issue.
But they center around the same few things:
-webkit-transform: translateZ(0); /* triggers GPU, sometimes fixes the issue */
transform: translateZ(0); /* non-webkit specific */
If this doesn't quite do the trick, try:
-webkit-backface-visibility: hidden;
backface-visibility: hidden;
-webkit-perspective: 1000;
perspective: 1000;
If this also fails, try this:
-webkit-transform: translate3d(0, 0, 0);
transform: translate3d(0, 0, 0);
You can read about each one of them through the W3C. But they have all worked for me on different circumstances with not fluid animations, and flickering ones, including some very odd ones, a lot jumpier than your fiddle.
They would go in the div being animated.

How to optimize highly detailed jQuery animations for mobile

I am working on a project, with no BoilerPlate, right now that uses a lot of jQuery animations such as paralax of several elements and the movement of 20 small .png images of clouds in the background (to make a cloud time-lapse) which run very slow and laggish on mobile devices. I want the same UX for both desktop and mobile environments. I am using mediaQueries to use smaller images/elements for smaller screens, but this doesn't seem to optimize mobile performance like I thought it would. I am familiar with HTML5-Boilerplate and BP-Mobile but am not sure if either one will help with my problem.
How can I make these particular effects run smoothly on mobile?

I would try to see if CSS3 animations have any effect. jQuery animate has severe performance drawbacks compared to CSS3. Even on a regular computer it is much smoother.

Firefox Image Performance

I'm going steadily more mad if this continues:
Firefox versions 6 - 13 seem to have serious image-rendering performance issues on Mac and Windows XP.
Whether I move multiple Images around in a DIV via position: absolute; left: Xpx or using CSS3 transform: translateX(Xpx); or even in a canvas element the images stutter heavily while being moved around.
You can check my latest Canvas test here: http://jsfiddle.net/5YCmH/6/
My question is; why is this happening?
As I see and read it on the web CSS3 and Canvas should be hardware accelerated by now.
So I checked the various settings in about:config and even reset them to default. Nothing works. While Safari and Chrome are rendering everything smoothly, Firefox looks like IE7.
I tested on 3 different machines, same problem everywhere. Whats happening people?
Any pointers or insight would be helpful!
PS:
I haven't used FF much since I switched to Chrome like one year ago. Before that I made an image sliding widget and tested it in FF 3.6.xx and it worked smoothly (using the position: absolute; left: xx; approach). Now I'm testing code I primarily developed in WebKit browsers also in FF and it doesn't work at all.
Is this real life? I feel funny.
EDIT:
Here's another fiddle showing the same stuttering with old-school animation: http://jsfiddle.net/XZAE6/3/
And with CSS3 translateX(): http://jsfiddle.net/h3UNk/3/

To answer your question: Yes, this is real life... ;)

The problem could possibly be remedied by using smaller images. Your aquatics.jpg is 193 kilobytes and velodrome.jpg 140 kilobytes. I'm sure the size can be reduced by at least 50 % without noticeable loss of image quality.

Are CSS3 keyframe animations smoother than property transitions?

I've got a mobile web app that uses Zepto to create transitions between pages. Animation is super smooth on desktop, but pretty choppy on my iPhone 4. Are animations more performant than transitions? What's the difference between animations and transitions, aside from granularity of control?

This is not a transition vs. animation question - this is a transform vs. property change question.
Content can be moved around a screen in multiple different ways: the most common two are position property (left, top, margin-left, scroll-position etc.) changes and transforms. On iOS, now in version 5, position property changes are done in pixel increments on the CPU - there is no sub-pixel tweening, so the movement, particularly on older non-retina displays is jerky.
In contrast, transforms - notably 3D transforms are done on the GPU, so you get very smooth movement and sub-pixel tweening.
(Note that some desktop browsers do GPU accelerated position property changes - like IE9 - so there is no difference visually between the two approaches)

I'm no expert, but I assume it's the way the browser handles animations.
It probably takes a more sophisticated and expanded way to handle the multistate animations offer, rather than the simple 2 states transitions have.