Webkit + jQuery + SuperBGImage: full-browser image

2019-06-26 12:44发布

问题:

This image best illustrates the problem:

I'm customizing a WordPress theme that uses SuperBGImage. In Safari 5.1 and Chrome 13, when resizing the browser window, images aren't anti-aliased smoothly and artifacts are clearly visible. You can readily compare the SuperBGImage demo to the production site...

SuperBGImage Demo vs. My Project

I've added demo images to the WordPress site (personal category) for direct comparison. The image of the cherries is the most obvious.

I've been working at this for a while, and have attempted the following to no avail:

  1. Tried adding a 2px border to slideshow images, which solved a barely-related problem with CSS3 transforms.
  2. Reverted scaling algorithm, which I had modified to never crop images.
  3. Added exact same image files used in the demo.
  4. Tried adding a box-shadow to trigger smoothing.
  5. Diff'd all modified JS and CSS trying to find a potential oversight. (image-rendering: optimizeQuality; and -ms-interpolation-mode: bicubic; have remained consistently intact.
  6. Confirmed that the SuperBGImage works as expected with jQuery 1.3.2 (demo) and 1.6.2 (project).
  7. Built a simplified demo and confirmed that the problem is not with my modified SuperBGImage JS. (Only difference is cropping method.)

When viewing the SuperBGImage demo, you'll notice smoothing take place about half a second after you've released the adjusted window. This subtle shift is absent from my project, though it used to be working. Does anyone know what could cause this difference?

Unlike most projects, I regrettably don't have this in source control so I can't just step back through revisions to isolate the problem.

For those who'd like to fiddle with a simple demo: http://jsfiddle.net/4ZcPF/

回答1:

The answer is to use this CSS3 property:

-webkit-optimize-quality

This is the proper solution, although it may or may not be effective for the following reasons:

  • The interpolation quality was considered an implementation detail until very recently (meaning the browser could have random results and be valid by rules of the standards bodies).

  • This property was strongly advocated by artists, actually because they wanted to be able to turn off high quality scaling for pixel art. It took over a year of debate to get everyone to agree on it.

  • The webkit patch was just checked in to support this in May 2011, so the time for it to be actually in a Safari update that your users have will take a little while.

IE and Firefox have had working solutions for a while under proprietary CSS properties.

Eventually this property will drop the webkit prefix and become a standard across all browsers.

If you want the gory details behind the development, see this thread: http://code.google.com/p/chromium/issues/detail?id=1502