TL; DR
（非常に良いアイデアを提案している）トーマスSchindlの記事JFace-Viewer and Eclipse Databinding with > 10.000 Objectsに基づいて、私は定期的に変換したいのですがにObservableListTreeContentProvider、VisibleRangeChangedListenerとEclipse Data Bindingを使用Nebula's GridTreeViewerにTreeViewer +複数ITreeContentProvider実装は「怠惰」（lazier）と負荷データをオンデマンドします。TreeViewer：既存ITreeContentProvidersと「怠惰」ObservableListTreeContentProvider間のブリッジ
既存の通常のITreeContentProvider実装をObservableListTreeContentProviderで同じ階層を使用するように書き直すにはどうすればよいですか？ 古いソリューションと新しいソリューションの間に「橋渡し」をすることはできますか？ DelegatingListPropertyどういうわけかthis？他のアイデア？
私はいくつかの、あまりにも簡単な例を見つけましたが、私は本当にこのような複雑な階層ツリー形式でデータバインディングを使用しての概念を得ることはありません。
例の木&コンテンツプロバイダー：
コンテンツプロバイダ1 .:
|- A1
|-- B1
|-- MyMessage1
|- A2
|-- B2
|-- MyMessage2
コンテンツプロバイダ2：
|- C1
|-- D1
|-- MyMessage1
|- C2
|-- D2
|-- MyMessage2
長い説明
私は私のビューを持っています表示大量のオブジェクト古典ITreeContentProviderとLabelProvider + ITableLabelProvider実装とカスタムTreeViewerを使用して、階層ツリー形式でTS。また、この階層が表示される形式をユーザーが選択できるメニューもあります。ユーザーが別の表示形式を選択すると、別のITreeContentProviderの実装がビューアに設定され、プログラムによってビューアがリフレッシュされます。
それは動作しますが、原因要素の膨大な数には時々、遅いできる項目を表示し、UIを（いくつかのケースでは、100-200k行、それだけで動作するように持っている、理由は聞かないでください）ツリーアイテムのように多くのリスナーがあるので、ビューのリフレッシュが多くの時間を要し、フリーズは、等...
は、だから私はすでにモデル要素を持ちながら怠惰なソリューションのいくつかの種類を使用したいですメモリにロードされます。
私はすでにSWT.VIRTUAL and ILazyTreeContentProviderを試しましたが、（viewer.setUseHashlookup(true)を使用していても）ひどくうまくいきました（スクロールすると、TreeItemsが読み込まれるのに多くの時間がかかり、並べ替えやフィルタリングなどの問題がありました。 ）。
今私はトーマスSchindlのブログ記事を読む：JFace-Viewer and Eclipse Databinding with > 10.000 Objects。私が試してみたいと思い、この使用Eclipse Nebula GridのGridTreeViewerと+（もあるITreeContentProvider実装）ObservableListTreeContentProviderと（記事のような）VisibleRangeChangedListenerと 『怠惰』ラベル・プロバイダー。 既存のITreeContentProvider実装を何とか使用し、これと新しいObservableListTreeContentProviderの間に「ブリッジ」を構築できますか？ 、そのAPIとそのアプローチは全く異なるものである
はところで私は Nebula NatTableを確認し、私はそれが非常に難しいこの新しいソリューションを既存のコンテンツプロバイダを移行することが判明（子から親へ行くの階層ではなく、逆の方法） Treesに関する文書はまだ空です。