Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. 今どきのWebブラウザは複数のプロセスで動くことが前提になっている。Chromeで言えば、メイン(UI)プロセスとレンダラープロセス。Firefox用語であればChromeプロセスとコンテンツプロセスという感じで別れて動作している。Webコンテンツはコンテンツ用のプロセスで表示され、文字入力はUI用プロセスで動作している。だから入力された文字はコンテンツ用のプロセスへプロセス間通信で送られ、コンテンツ用プロセスで内部的に描画されるいることになる (実際に画面上に描画されるのがGPUプロセスだったりUIプロセスだったりするけど)。 今どきのOSで使われるIMEのためのAPIは入力された文字をただアプリケーションに渡すだけではなく、様々なことを要求してくる
Apple M1速いね、ってことで、それはいいとして、それ以外にも色々Appleの用途に最適化している点があるらしいというツイートがあった。ちょっと読んでてマジで?となったのでここにメモしておこう。 私はというとこんなCPUレベルの話が効いてくるようなプログラムは書いたことないので、誤解もあると思う。ゆるして 1/ In case you were wondering: Apple's replacement for Intel processors turns out to work really, really well. Some otherwise skeptical techies are calling it "black magic". It runs Intel code extraordinarily well. — Robᵉʳᵗ Graham😷, provocateu
OpenAI co-founder and Chief Scientist Ilya Sutskever is leaving the company
Basuke Suzuki さんをゲストに迎えて、iPad Pro, Google Fi, Edge, C++, DJI Osmo Pocket などについて話しました。 Show Notes Coronado Brewing Company | Stay Coastal Rebuild: 221: Something's Plugged Into His iPad (basuke) Here’s how Google Fi will work with iPhones Google Fi OneNote Notion nativefier: Make any web page a desktop application Microsoft's Edge to morph into a Chromium-based, cross-platform browser Goodbye, Edge
Jan 15, 2018 by Addy Osmani, Mathias Bynens & Ryosuke Niwa @rniwa_dev In 2014, the WebKit team at Apple released Speedometer 1.0, a benchmark for web app responsiveness. It simulates user interactions in web applications, using TodoMVC to orchestrate adding, completing, and removing todo items. Speedometer repeats these actions using DOM APIs that were extensively used in real-world applications.
canvas要素(キャンバスようそ、英: canvas element)とは、HTML5以降のHTMLの一部で、動的な2次元ビットマップ画像の描画のためのHTML要素。 歴史[編集] Mac OS X v10.4の内部でWebKitコンポーネントとして、DashboardウィジェットやSafariでのアプリケーションを強化するために、2004年[1]にAppleが最初に導入した。後に、Mozilla FirefoxやOperaでも採用され、WHATWGで、新しい標準規格として標準化された。 2009年の夏頃に、文字列描画のAPIとピクセル操作のAPIが追加になり、ウェブブラウザに実装された。 その後、HTML Canvas 2D Context, Level 2 が作られ、2012年12月17日[2]に最初の W3C Working Draft が発表になった。imageSmoothing
Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. 久々にwebkit-dev見てたら、こんなメールがあったりしてウケた。差出人はAppleの中の人ね。 Hi WebKittens, I’d like to propose removing the Pointer Lock API code from WebKit. The code hasn’t been touched for 12 months, and AFAICT no ports are building with ENABLE(POINTER_LOCK). Is anyone currently building (and shipping / planning to ship) this API? Other thoughts? -Kl
Apple’s new Objective-C to Javascript Bridge May 13th, 2013 • Development • Nigel Brooke A few month back, Apple quietly slipped a very nice Objective-C to Javascript bridge into WebKit. Since the first commit while we were busy celebrating New Year’s Eve, it has been fairly actively developed and improved. This new API supports straightforward embedding of the JavaScriptCore interpreter into nati
先週、Webブラウザーの世界にふたつほど衝撃的なニュースが走った。ひとつ目はMozillaがSamsungと共同でプログラミング言語Rustをベースにした新Webレンダリングエンジン「Servo」の開発を進めていくと表明したこと、そしてもうひとつが今回の主題、GoogleがWebKitを離れて「Blink」への移行を表明したことだ(開発者向けバイナリーを配布するGoogle Chrome Canary(28.0.1468.0 canary)では、すでにBlinkが含まれている模様)。 Mozillaの抱えるGecko、AppleとGoogleが推進するWebKit、そしてMicrosoftのTridentの3つは、Webブラウザー業界においてシェアのほとんどを握る3大勢力となっている。その勢力のうちのふたつが従来の技術とは別の新しいエンジン採用と開発推進をほぼ同時に発表したことは、今後のト
ついにWebKitからGoogle勢が分裂してBlinkという新しいフォークが出来てしまった。 折りしもmozillaがレンダリングエンジンをRustで作り直すという挑戦的なニュースも重なり、 新年度早々Web業界ウォッチャーには衝撃が走った。 さて、このBlinkのフォーク騒動だけど、理由は大きく2つあると思う。 一つは、性能や安全性向上のためのリアーキが現状のWebKitのtrunkでは難しいから。 二つは、WebKitのコミュニティ上でのApple勢とGoogle勢の信頼関係が崩れたため。 一つ目の性能に関する理由は明白。Blinkの公式サイトにもあるような、iframeのsandbox化、ネットワークコードの簡潔化、DOMをJSヒープに移動させることによるDOM操作の高速化などを、様々な移植層に適合した形で実現するのは技術的にも政治的にも非常に難しいためだ。 そういったドラスティッ
YahooメールのspamをiPadの「メール」から削除しようとしたら、プレビューが表示されて、以後3分ぐらいに一度、「Macのメールウイルス対策には...comへ」の日本語アラートが数分おきに現れるようになった。iOS4まで標準だったアラートなので、[OK]を押すまで他のことは何もできない。とりあえずこのアラートは、「設定」の「通知」で空白アイコン、無名のエントリを「オフ」設定にすることで出なくすることはできたが、たいへん気分が悪い。 おそらくプレビューでWebKitが呼び出されて、WebKitのセキュリティホールを使って何らかのトロイの木馬が仕込まれたのだと思う。メールを開いたつもりもなく、「編集」で削除しようとしただけでプレビューが出たように記憶するのだが、もしかしたらタップして踏んでしまったのかもしれない。 きょうのthreatpostの投稿に、iOS 6にも存在するWebKitの
2012/09/11 9月8日、HTML5コミュニティ「html5j.org」が主催するイベント「HTML5 Conference 2012」が慶應義塾大学日吉キャンパスで開催された。コミュニティとしては初めての1000人規模のイベントであったが、応募開始からわずか2日間で席が埋まってしまうほどの盛り上がりをみせた。全22のセッションのうち、パネルディスカッション「Web最先端、エキスパートたちの視点から」では、グーグルの及川卓也氏、Futomiの羽田野太巳氏、シーエー・モバイルの白石俊平氏、NTTコミュニケーションズの小松健作氏が登壇。「たくさんの優れた技術がある中で、なぜHTML5が今、こんなにも盛り上がりを見せているのか」という議論が行われた。 羽田野氏は、「冷めた言い方かもしれないが、HTML5が盛り上がったのは、Appleショックがあったからである」と話した。「仮に、iPhone
http://d.hatena.ne.jp/mala/20120220/1329751480 の続き。書くべきことは大体既に書いてあったので、補足だけ書く。 Googleは制裁金2250万ドルを支払うことでFTCと和解した http://jp.techcrunch.com/archives/20120809google-settles-with-ftc-agrees-to-pay-22-5m-penalty-for-bypassing-safari-privacy-settings/ まさか(まともに調査されれば)こんなことになるとは思わなかったので驚いた。異常な事態である。そしてGoogle側の主張を掲載しているメディアが殆ど無いのも異常な事態である。 2250万ドルもの制裁金(和解金)が課せられるのは、2009年に書かれたヘルプの記述が原因だという。 問題の記述 http://obam
夏ということで、怖い話をします。 Webアプリケーション開発者の皆さん、聞いて下さい。 時間がない人や、他の人に問題を説明するときなどには簡潔にまとめた版をどうぞ。 これは2011年12月27日にAppleに報告したSafariの問題です。Appleからは修正する予定はないという回答を貰っていましたが、2012年7月25日にリリースされたMacのSafari 6のアドバイザリによるとどうもMacのSafari 6では修正されたようです。 About the security content of Safari 6 http://support.apple.com/kb/HT5400 WebKit Available for: OS X Lion v10.7.4, OS X Lion Server v10.7.4 Impact: Visiting a maliciously crafted
レスポンシブWebデザインを実装する際、画像の扱いは一つの課題として残っています。現在、PHPを使用した「Adaptive Images」やJavaScriptを使った「Responsive-Images」などが現実的な対応策としてありますが、どちらもApacheの設定を必要とします。レスポンシブWebデザインが広まって標準的な実装方法の一つになろうとしている今、サーバサイド技術に依存しない解決策が早急に求められています。 そんな中、HTMLの仕様策定の一端を担うWHATWG(Web Hypertext Application Technology Working Group – ワットダブルジーと読む)で、新たな仕様が検討されています。 では、どんな議論がされていて、今どんな状況なのか? なかなか複雑なことになっているようなので、調べてまとめてみました。 ※この記事は、レスポンシブWeb
※この記事の完成度は85%ぐらいなので後で追記します。 http://webpolicy.org/2012/02/17/safari-trackers/ http://online.wsj.com/article/SB10001424052970204880404577225380456599176.html http://blogs.wsj.com/digits/2012/02/16/how-google-tracked-safari-users/ 合わせて読みたい。 http://trac.webkit.org/changeset/92142 https://bugs.webkit.org/show_bug.cgi?id=35824 一番上のJonathan Mayer氏の記事については純粋に技術的なレポートなので、特におかしなことは書かれていない。元はといえばSafariのCooki
「iOS 4.3でホーム画面に保存したWebアプリは動作が遅い」と言われたら、誰でもエッと思ってしまう。実際、iOS 4.3のSafariで動作するiPad 2のSunspider-0.9.1の結果が2100ms前後であるのに対して、フルスクリーンモードで動作する状態でホーム画面に保存したものを実行すると約5200msに落ち込むのだ。 iOS 4.3のSafariのSunspider (0.9.1)ベンチマークは2144ms 同じデバイス、同じネット環境でもホーム画面に保存したフルスクリーンモードで実行すると5225msに これをThe Registerは「iPhoneのホーム画面で、オープンなWebアプリに手錠をかけるApple」という見出しで報じ、その中で「AppleはWebアプリの品質が低く感じられるように、ちょっとした不具合を利用している」という匿名のモバイルWebアプリ開発者の指
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く