問題タブ [webkit-transform]

Webkit ベースのブラウザーにいくつかのプラグインを追加して、JavaScript の機能を拡張する方法を学びたいと考えています。

開始できるリンクまたはチュートリアル。

http://rvr.typepad.com/wind/2011/10/webkit-extending-javascript-1.htmlを調べました

GTK+ を使用していましたが、C/C++ での Webkit 拡張を探しています。

私はwkhtmltopdf（Webkitレンダリングエンジンを使用）を使用してHTMLファイルをPDFドキュメントに変換しています。生成されるPDFはA4です。言い換えれば、それらは固定された寸法を持っているので、幅が制限されています。

私のPDFの表の1つには、パズルのように複雑につなぎ合わされた画像が含まれており、多くのスペースを占めることがあります。

結果のパズルをA4PDFの制約に合わせるために、CSSプロパティ-webkit-transform：scale（...）;を適用しています。

これにより、パズルが美しく拡大縮小され、それでもはっきりと判読できますが、何らかの理由で、パズルを含むテーブルが右に押し出されます。左マージンを明示的に0に設定しているにもかかわらず、パズルテーブルの左側にかなりのマージンが追加されているようです。

興味深いことに、Webkitトランスフォーメーションのスケールが小さいほど、左側のマージンが大きくなります。したがって、たとえば、scale（0.75）を使用すると、結果の左マージンは約200ピクセルになります。scale（0.5）を使用すると、結果の左マージンは約400ピクセルになります。

パズルテーブルを左に絶対、固定、相対位置を使用して左に揃えてみました：0。また、左に浮かせたり、text-alignを左に設定したコンテナに貼り付けたりしてみました。これらの手法はどれも機能しません。

この左マージンがどこから来ているのか、そしてそれを削除/回避する方法はありますか？

立方体の面を2回回転させ、その1つの面を片側で平らにしたいと思います。

これが私が達成しようとしていることについての実例です：http：
//i.imgur.com/00yAQ.png

私は今ここに持っているものを置きます。90度は形を隠すので、進行状況を示すために45度を使用していることに注意してください。 http://jsfiddle.net/s6jwC/1/

ありがとうございました！

私は非常に奇妙な問題を抱えています:

Web サイトでいくつかの製品を表示するために、次のような DIV 構造があります。

まあ、あなたは約を見ることができます。私のコードのコピー。PRODUCT_OVERLAY を webkit-transform でアニメーション化するので、ホバー時に製品を完全にカバーします。何が起こるかというと、動きを開始するときとそれを終了するとき、ホバリングされた後のすべての製品が数ミリ秒間点滅します (消えて表示されます)。

さらに奇妙なことに、3 つ以上のページがある場合にのみ発生します (カルーセルのように、WIDE_CONTAINER を水平に移動してページを切り替えます)。

少し複雑な構造なので、たくさんのことが原因である可能性がありますが、製品がホバリングされた後にのみ発生し、1ページまたは2ページがある場合は決して発生しないという事実は、私が何かしていないものがあると思わせます.見る...

3ページのケースのJSFIDDLEは次のとおりです(問題が発生する場所):

http://jsfiddle.net/BVV24/1/

そして、ここに 2 ページの cas (HTML のみを変更し、1 ページを削除しました):

http://jsfiddle.net/BVV24/2/

ところで、これは Safari (Webkit) でのみ発生し、Google Chrome (Webkit) では発生しないことに気付きました...

前もって感謝します！

ハードウェアアクセラレーションCSS3タグ（以下のコードを参照）を使用したアニメーションは、SamsungGalaxySIIIのGoogleChromePCブラウザーおよびAndroidブラウザーで適切に機能します。ただし、Samsung GalaxyTab10.1のAndroidブラウザでは同じことが機能しません。Samsung Galaxy Tabデバイスでハードウェアアクセラレーションによるスライドイン/アウトアニメーションを実現するにはどうすればよいですか？

よろしく、ビナヤ

HTMLページでdivをスケーリングしようとしています。このdivには、多くのキャンバス要素とその他のdiv要素が含まれています。基本的に、このdivは、ページ内の他のすべてのアイテムのコンテナとして機能します。Chrome「23.0.1271.95m」とIOS6.0サファリでは、このdivの右側と下部にあるアイテムは、スケーリング後に表示されません。ウィンドウのサイズを変更する（またはiPadの向きを変更する）と、divが正しくスケーリングされ、アイテムが表示され始めますが、特定のサイズになると再び消えます。

これは、IOS5.0および以前のchrome/safariバージョンで正常に機能していました。これは最新のWebkitバージョンのバグですか？また、この動作を回避するための回避策はありますか？

Amazon の電子書籍の .mobi ファイル内で webkits transform 回転プロパティを使用しようとしています。CSS でプロパティを使用すると、各単語の右下に非常に小さいが目立つ黒いアーティファクトが表示されます。文末のピリオドのようなものですが、きれいではありません。カメラのレンズに付着した小さなほこりのように見えます。この問題は、第 1 世代の Kindle Fire で「のみ」表示され、見た目が素晴らしい Kindle Fire HD 8.9 では表示されません。どのブラウザもこの動作を表示していません。他の書体でも試してみたので、フォントではないことがわかりました。 .変換プロパティを削除すると消えます.それは明らかです.他に何か追加する必要がありますか?主なことは、KF HDに表示されないことです.おそらく その結果、HD の画面 ppi が 2 倍になりましたか? もしかしたら、まだそこにあるのに見えないだけですか？ご意見やご提案をいただければ幸いです。

内部にdivドラッグ可能なアイテムがある状況があります。ただし、親divが を使用してスケーリングされる-webkit-transformと、ドラッグ可能なものは明らかに適切に機能しなくなります。

ここでシナリオを再現しました。

ご覧のとおり、親の縮尺がまったく異なる場合でも、ドラッグ可能なアイテムはドキュメントに対して相対的に移動します。

私はJSの変数としてスケール（1.5例では）を持っているので、それを使うことができますが、どこで？ドラッグ距離をスケールで割る必要がありますよね？どこでこれを行うことができますか?

編集:関数をdrag-event に設定しようとしましたが、実際にドラッグ距離を変更する方法を理解できませんでした。

Edit2: jQuery UIソースを掘り下げましたが、イベントからこれを行う方法がないようですdrag:

ご覧のとおり、コールバック関数の戻り値は保存されません。要素の位置はコールバックが発生した後に変更されるため、コールバック内の CSS を変更しても機能しません。

この文字列でブラウザー内検索を使用すると、関連するコードをここで確認できます。

CSS3とtranslate3dをテストするための小さなアプリケーションを開発しています。アイデアは、画面上でランダムに移動する複数のDIVをレンダリングすることです。これは一種のパーティクルシステムです。おそらくWebGLまたはCanvasを使用してパフォーマンスを向上させることができますが、モバイルブラウザーでもスムーズに動作させたいので、パフォーマンスにはDOM操作の方が適していると思いました。

このURLで数時間後に結果が見つかります

DIVの数を増やすために可能な限り最高のパフォーマンスを達成したいと思います。

しかし、ここに私の問題があります。ChromeまたはSafariでTimeLineを使用したときに見つけた「レンダリングの問題」があります。時々、ページ全体がレンダリングされ、SafariiPhoneまたはChromeAndroid+iPhoneで認識できる小さなラグが生成されます。

ですから、もしあなたの一人が挑戦に挑戦しているなら、私は多くのことを試みましたが、この高価な再描画を避ける方法を理解していませんでした。

ところで、このスニペットを最適化するための追加のアイデアがある場合は、遠慮なく返信してください。

ありがとう

----------更新1-----------

Ariyaのアドバイスに基づいて、コード（url）で更新し、左上のみを使用して別のテストを追加しました。Chromeが提供するFPSカウンターに基づくと、ほぼ同じフレームレートの左上のプロパティを使用すると、fpsがより安定していることがわかります。CSS3バージョンを最適化してパフォーマンスをさらに向上させることができるかどうか考えていますか？GPUアクセラレーションを使用したcss3の方が高速ですが、おそらく何か間違ったことをしました。

----------アップデート2-----------

requestAnimFrameを使用するようにコードを更新し、再描画が必要な場合にのみコードを起動します。そして、cssで定義したパフォーマンスグレーグラデーションの背景を殺しているのは、頻繁に再描画され、パフォーマンスを殺していることを発見しました。ただし、純粋なパフォーマンスの観点からは、上/左はCSS遷移よりも優れているようです:(。