HN公開：驚くべき実験を目にして、シンプルなバージョンを作りました

 (github.com/Momciloo)
2 ポイント 投稿者 GN⁺ 2023-11-26 | 1件のコメント | WhatsAppで共有
  • このリポジトリは Björn Staal の取り組みに着想を得て作られたシンプルなコード実験で、元のアイデアに関する追加情報へのリンクも提供している
  • ローカル実行は npm i の後、ターミナルを2つ開き、一方でサーバー、もう一方でクライアントの静的サーバーを実行する方式
  • サーバーは node server/server.js で実行し、クライアントは cd client && http-server で実行する
  • 実験の確認は、ブラウザのタブを2つ開き、それぞれ localhost:8080?b=1 と localhost:8080?b=2 を開く方式
  • 今後の計画には、localStorage 専用モード、無制限のウィンドウ数のサポートと URL クエリの削除、WebRTC への移行が含まれる

プロジェクト概要

  • Momciloo/fun-with-sockets は Björn Staal の取り組みに着想を得たシンプルなコード探索プロジェクト
  • 元のアイデアに関する追加情報は LinkedIn の投稿にリンクされている
  • README には実験画面の録画画像が含まれている

ローカルでの実行方法

  • まず依存関係をインストールする
    • npm i
  • もう1つターミナルを開き、合計2つのターミナルを使用する
  • 1つ目のターミナルでサーバーを実行する
    • node server/server.js
  • 2つ目のターミナルでクライアントディレクトリへ移動した後、静的サーバーを実行する
    • cd client && http-server
  • ブラウザで2つのタブを開き、それぞれ異なるクエリ値を使用する
    • localhost:8080?b=1
    • localhost:8080?b=2

今後のアイデア

  • localStorage モードのみを実行できるフラグの追加を計画している
  • 無制限の数のウィンドウをサポートし、URL のクエリを不要にするオプションを計画している
  • 実装方針を WebRTC へ移す計画がある

関連記事

1件のコメント

 
GN⁺ 2023-11-26
Hacker News のコメント

  • 素晴らしいデモ。マルチモニターではどう動くのか気になる
    また、他の人から直接インスピレーションを受けたことを自発的に明かし、出典を認めている点も良い。ソフトウェア業界にこういう人がもっと増えてほしい

  • Krita、Inkscape、Gimp のようなペイントソフトでは、レイヤー管理にこういう方式や似た方式が役立ちそう
    アプリケーションウィンドウ全体の中にタブパネルとして簡単に実装し、選択されたタブのレイヤーを編集作業のアクティブレイヤーにすればよい

  • 以前にもウィンドウの位置とサイズを活用したデモがかなりあったのを覚えている。物理シミュレーションのデモもあって、液体だったのか複数の固体だったのかは覚えていないが、あるウィンドウから別のウィンドウへ物体を落とせた
    ソケットまでは必要なく、ウィンドウ間のメッセージチャネルだけでも可能そう。ウィンドウが子ウィンドウを開くと、通常は互いに分離されるタブ／ウィンドウとは違って特別なアクセス権があるので、ローカル専用版も簡単に作れそう

  • こういうものが好きなら WindowKill も楽しめるかもしれない。Asteroids に似たビデオゲームで、互いに重なり合い相互作用する複数のウィンドウを巧みに使っている
    ウィンドウの境界も撃たなければならず、そうしないとウィンドウが縮んでいく。ゲーム後半にはボス敵が入った追加ウィンドウも現れる
    プレイ動画: https://youtu.be/7iP68FZWVxM

  • オリジナルの Bjorn Staal のツイートリンクが消えているが、これが何だったのか見られるリンクがあるのか気になる

  • ブラウザウィンドウで Pong をする素晴らしいデモを思い出した: http://stewd.io/pong/

  • これがどういう意味なのか説明してもらえるだろうか。GitHub ページの GIF も正しく理解できているか分からず、単にウィンドウ同士がデータを共有しているように見える

    • 重要なのはウィンドウ同士が通信していることよりも、ブラウザ API でウィンドウ座標を公開して使っている点にある
    • 複数クライアントと単一サーバーの構成に見える。各ウィンドウが個別のクライアントで、画面のジオメトリ情報をサーバーに送ると、サーバーがクライアントごとに異なる配置を返し、コンテンツが複数ウィンドウにまたがる1つのオブジェクトのように見えるようにしている方式だと思う

  • 良い。フォーカスされたウィンドウの四角形が一番上に描かれるほうが自然に見える

    • 単に透明度を使っているわけではないことを示すために、そうしているのではないかと思う

  • ところで、なぜ遅延が発生するのか分からない。この程度なら即時に処理できるほど単純なはずでは？

    • ブラウザ内で動いているから。単純なマウス移動と単純なオブジェクト座標の変更の間にも、イベントをインタープリタまたはコンパイル済みコードに渡し、状態変化を画面まで送るシステム／アプリケーション層が多く挟まっている
      ネイティブにしても、別々の2つのウィンドウを即座にまったく同じように動かすのは常に些細なことではない。たとえば、一部の GUI ツールキットでは滑らかなウィンドウリサイズが不可能になるという記事もあった。すべてを自作したとしても、システムがウィンドウに素早く通知し、画面にビットマップを押し出せるだけの性能が十分にあることを期待しなければならない。より良い方法は、システム全体のソフトウェア／ハードウェアコンポジタを使い、オブジェクトごとのレイヤーを追加したうえで座標だけを変えることだが、その場合でもコンポジタが必要なときに毎秒60/120/144回以上の更新を処理できるほど優れている必要がある
    • ウィンドウ位置の取得は残念ながら遅い。ブラウザ機能の性質だ
    • ネットワークを経由せず postMessage API を使えば、もっと即時性が高くなるのか気になる
    • バックグラウンドのウィンドウやタブの優先度が下がることも一因かもしれない
    • おそらく WebSocket のネットワーク遅延のせいで、個人的にもウィンドウ位置の更新がときどき妙にカクつくことがあった

  • LocalStorage の面白い使い方の例
    別のブラウザウィンドウで設定が変わったときに対象ウィンドウを更新するため、同じLocalStorage 共有テクニックを使ったことがある。更新には storage.onChanged イベントを聞くだけでよい

    • これはローカルストレージを使っているようには見えない。WebSocket ベースのサーバーが、他のボックスの位置を動かすたびにクライアントへ送る構造だ