Javascript（重新）压缩的Javascript概念证明

时间：2015-02-18 12:46:27

标签： javascript compression gif bzip2

我的程序Precomp可用于进一步压缩已压缩的文件格式，如GIF，PNG，PDF，ZIP等。粗略地总结，它通过解压缩压缩流，重新压缩它们并存储预期压缩流和实际压缩流之间的差异来实现。例如，来自维基百科的this rotating earth picture从1429 KB压缩到755 KB。该过程无损，因此可以恢复原始GIF文件。

GIF文件格式的算法可以相对容易地隔离和实现，所以我在思考JavaScript中的概念验证实现。这将导致Web服务器发送压缩版本的GIF文件（.pcf结束，本质上是一个bzip2压缩文件 GIF图像内容）和客户端解压缩数据，重新压缩到GIF并显示它。以下事情将要完成：

  • 网站作者将使用标准版本的Precomp来压缩他的GIF文件，并将这些文件与JavaScript一起提供，而不是使用JavaScript进行客户端重新压缩。
  • 客户端会解压缩bzip2压缩文件，这可以使用one of the existing bzip2 Javascript implementations完成。
  • 客户端会将图像内容重新压缩为原始GIF文件。

该过程是带宽与客户端CPU使用率的交易。

现在我的问题如下：

  • 加载不同文件的过程是否存在任何一般问题？＆＃34;转换＆＃34;它到GIF？
  • 您建议在客户端完成之前显示什么（图像占位符）？
  • 我需要做些什么才能确保缓存.pcf文件？如果没有缓存，带宽节省是无用的。
  • 如果停用JavaScript，有没有办法显示原始GIF，但如果激活JavaScript则避免加载GIF？
  • 我可以为用户提供配置行为的方法吗？例如。在移动设备上，有些可能会避免带宽，但其他人可能希望减少CPU使用率。
  • 是否可以按照假设显示隔行扫描的GIF（从粗略版本到最终图像）？这将需要在不同的再压缩阶段多次更新图像内容。

1 个答案:

答案 0 :(得分：6)

让我们首先回答您的具体问题。下面的代码示例。

问＆安培; A

  
      
  1. 加载不同文件的过程是否存在任何一般问题？＆＃34;转换＆＃34;它到GIF？
    2.   

主要问题是并发症。你正在有效地编写一个浏览器插件，就像JPEG2000那样。

如果您正在编写真正的浏览器插件，每个主流浏览器都会采用不同的方式，并偶尔更改插件格式，因此您必须积极维护它们。

如果你正在编写一个JS库，它将更容易编写和维护，但它将没有特权，并受到cross original restriction等限制。

  
      
  1. 您建议在客户端完成之前显示什么（图像占位符）？
    2.   

取决于您的格式可以提供什么。 如果您提前对图像尺寸和小缩略图进行编码，则可以很早地显示准确的占位符。

这是你的格式，毕竟。

  
      
  1. 我需要做些什么才能确保缓存.pcf文件？如果没有缓存，带宽节省是无用的。
    2.   

与其他文件没什么不同。

在服务器端配置Expires and Cache-Control header，它们将被缓存。 <{3}}和Manifest也可以使用。

  
      
  1. 如果停用JavaScript，有没有办法显示原始GIF，但如果激活JavaScript则避免加载GIF？
    2.   

这很棘手。禁用JavaScript时，您只能prefetch，而不能使用属性。

这意味着您无法在某个指向.pcf文件的位置创建图像，并要求浏览器在JS不可用时重写src属性。

我认为支持无JS的最佳解决方案是使用document.write输出图像，使用noscript作为后退：

<noscript>
  <img src=demo.gif width=90>
</noscript><script>
  loadPcf("demo.pcf","width=90")
</script>

（某些库或框架可能会让您考虑<img src=demo.gif data-pcf=demo.pcf>。 这对您不起作用，因为浏览器replace elements＆＃39; demo.gif＆＃39;在您的脚本启动之前，导致额外的数据传输。）

或者，浏览器插件不受＆＃34;禁用JS＆＃34;设置，所以如果你做了插件，那么你不必担心它。

  
      
  1. 我可以为用户提供配置行为的方法吗？例如。在移动设备上，有些可能会避免带宽，但其他人可能希望减少CPU使用率。
    2.   

也许。您可以编写用户界面代码并将首选项存储在cookie或localStorage中。 然后，您可以检测首选项并在服务器代码（如果cookie）或客户端代码中切换逻辑。

如果您正在做插件，所有浏览器都提供可靠的偏好机制。 问题在于，每个浏览器都会采用不同的方式。

  
      
  1. 是否可以按照假设显示隔行扫描的GIF（从粗略版本到最终图像）？这将需要在不同的再压缩阶段多次更新图像内容。
    2.   

如果您向浏览器提供部分图像，他们可能认为图像已损坏并拒绝显示。 在这种情况下，您必须实现自己的GIF解码器和编码器，以便您可以浏览完整的占位符图像，只是为了安全。

  
      
  1. （新）我可以解码从其他网站加载的图片吗？
    2.   

我还必须重复警告，非插件JS图像解码不适用于will preload。 这意味着，所有.pcf文件必须与使用它的站点位于同一服务器，相同端口和相同协议上。

例如，您无法共享多个网站的图片或执行cross origin images等优化。

代码示例

以下是创建<img>的最小示例，加载gif，宽度的一半，然后将其放回<img>。

要支持占位符或渐进式加载，除了onload之外，请收听domain sharding而不是/。

  <!DOCTYPE html><html><head><meta charset="UTF-8"><script>
  function loadPcf( file, attr ) {
     var atr = attr || '', id = loadPcf.autoid = 1 + ~~loadPcf.autoid;
     document.write( '<img id=pcf'+id+' ' + atr + ' />' );
     var xhr = new XMLHttpRequest();
     xhr.responseType = 'arraybuffer'; // IE 10+ only, sorry.
     xhr.onload = function() { // I am loading gif for demo, you can load anything.
        var data = xhr.response, img = document.querySelector( '#pcf' + id );
        if ( ! img || ! data instanceof ArrayBuffer ) return;
        var buf = new DataView( data ), head = buf.getUint32(0), width = buf.getUint16(6,1);
        if ( head !== 1195984440 ) return console.log( 'Not a GIF: ' + file ); // 'GIF8' = 1195984440
        // Modify data, image width in this case, and push it to the <img> as gif.
        buf.setInt16( 6, ~~(width/2), 1 );
        img.src = URL.createObjectURL( new Blob( [ buf.buffer ], { type: "image/gif" } ) );
     };
     xhr.open( 'GET', file );
     xhr.send();
  }
  </script>
  <h1>Foo<noscript><img src=a.gif width=90></noscript><script>loadPcf("a.gif","width=90")</script>Bar</h1>

如果您不需要<noscript>兼容性（从而阻止Facebook / google +在共享页面时看到图片），您可以将pcf文件放在<img> src中并使用JS可以大量处理它们，因此您不需要为每个图像调用loadPcf，并且会使html 更多更简单。

<video>怎么样？

在理论上，你所设想的大多数是可行的，但也许你应该重新考虑。

从您提出的问题来看，您很难顺利地定义和推动您的愿景。 在WebM和onprogress中编码动画可能更好。

  1. 更好的浏览器支持返回IE 9 - 只需添加H.264即可成为use <video> instead。您需要dual format video来修改二进制数据。
  2. 尺寸：电影有许多选项和技巧可以减小尺寸，您学到的东西可以在将来重复使用。
  3. 渐进式： <video>有IE 10+，希望他们能尽快稳定下来。
  4. JavaScript： <video>不依赖于JavaScript。
  5. 面向未来：在您停止使用特殊格式之后很长时间内，许多程序都支持WebM和H.264。
  6. 具有成本效益：使用较小或较低质量的媒体创建低带宽选项比自定义格式更容易，更可靠。这就是维基百科和youtube以不同的分辨率提供媒体的原因。

    7. 对于非动画，PNG也可以进行颜色索引和7z had some techs for adaptive video（保持PNG格式）。 图标大小索引PNG通常小于相同的GIF。

    或许您的愿景（如pcf网站所述）能够编码许多不同的文件，而不仅仅是GIF。 这更像是支持新的网络协议，并且可能超出了简陋的JavaScript范围。 （例如，你将如何处理pdf下载或流媒体？）

相关问题
最新问题