TreeViewer для GridTreeViewer: мост между существующими ITreeContentProviders и "ленивый" ObservableListTreeContentProvider

TL; DR

Основываясь на статье Томаса Шиндла JFace-Viewer и Eclipse Databinding s > 10.000 Объектами (что предлагает очень хорошую идею), я бы хотел для преобразования регулярных реализаций TreeViewer + multiple ITreeContentProvider в туманность GridTreeViewer, которая использует ObservableListTreeContentProvider, a VisibleRangeChangedListener и привязка данных Eclipse до делает его "ленивым" (более ленивым) и загружает данные по запросу.

Как мне переписать существующие существующие регулярные реализации ITreeContentProvider для использования тех же самых иерархий с ObservableListTreeContentProvider?  Могу ли я создать "мост" между старым и новым решением? Используя DelegatingListProperty как-то вроде this? Любые другие идеи? Я нашел несколько простых примеров, но на самом деле я не понимаю концепцию использования привязки данных в таком сложном иерархическом древовидном формате.

Примеры деревьев и поставщиков контента:

Поставщик контента 1.:

|- A1
   |-- B1
       |-- MyMessage1
|- A2
   |-- B2
       |-- MyMessage2

Поставщик контента 2.:

|- C1
   |-- D1
       |-- MyMessage1
|- C2
   |-- D2
       |-- MyMessage2

Более длинное объяснение

У меня есть представление, в котором я показываю огромное количество объектов в иерархическом формате tree, используя пользовательский TreeViewer с классическим ITreeContentProvider и LabelProvider + ITableLabelProvider. Существует также меню, в котором пользователь может выбрать, в каком формате они хотят видеть эту иерархию. Когда пользователь выбирает другой формат отображения, единственное, что происходит, это то, что другая реализация ITreeContentProvider устанавливается в программу просмотра, и я обновляю программу просмотра программно.
Он работает, но из-за огромного количества элементов (в некоторых случаях, 100-200 тыс. Строк, пожалуйста, не спрашивайте причины, он просто должен работать), отображение элементов может быть медленным, пользовательский интерфейс иногда зависает, потому что в TreeItems так много слушателей, обновление представления занимает много времени и т.д.

Поэтому я хотел бы использовать какое-то ленивое решение, имея уже загруженные в память элементы модели.
Я уже пробовал SWT.VIRTUAL и ILazyTreeContentProvider, но он выполнялся плохо (даже при использовании viewer.setUseHashlookup(true)) и был проблематичным (при прокрутке, для загрузки TreeItems потребовалось много времени, было bugs, проблемы с сортировкой, фильтрацией и т.д.).

Теперь я читаю статью блога Томаса Шиндла: JFace-Viewer и Eclipse Databinding s > 10.000 Объектами. Я хотел бы попробовать это, используя Ebipse Nebula Grid GridTreeViewer и + ObservableListTreeContentProvider (который также является реализацией ITreeContentProvider) и VisibleRangeChangedListener и "ленивым" поставщиком меток (как в статье). Могу ли я каким-либо образом использовать существующие существующие реализации ITreeContentProvider и создать "мост" между этим и новым ObservableListTreeContentProvider?

BTW Я проверил туманность NatTable, но мне было очень сложно перенести существующие контент-провайдеры на это новое решение, его API и его подход (иерархия идет от ребенка к родительскому, а не наоборот), а документация, связанная с Деревья, по-прежнему пуста.

ОТВЕТЫ