Отбраковка элементов, находящихся за пределами видимой области

Из документов:

Средство рендеринга по умолчанию не выполняет отсечения области просмотра на стороне ЦП или обнаружения окклюзии. Если что-то не должно быть видно, это не должно быть показано. Используйте Item::visible: false для элементов, которые не должны быть нарисованы. Основная причина отказа от добавления такой логики заключается в том, что она увеличивает стоимость, что также нанесет ущерб приложениям, которые заботятся о хорошем поведении.

Итак, есть ли способ сделать это легко, не применяя его самостоятельно?

Обратите внимание, что в моем случае элементы, находящиеся за пределами видимой области, присутствуют, потому что они находятся в ScrollView, и они не прокручиваются.

Причина, по которой я хочу отбраковку, заключается в том, чтобы уменьшить использование ЦП для полной перерисовки сцены.


scroll qt qml qtquick2 culling
person Stefan Monov    schedule 19.04.2017    source источник
comment
Вы используете программный рендерер? Потому что Qt Quick всегда рендерит всю сцену на графическом процессоре, и это не сильно влияет на это.   -  person Kuba hasn't forgotten Monica    schedule 19.04.2017
comment
Было бы довольно дилетантски, если бы он на самом деле отображал то, что на самом деле не отображается. Мне удалось сэкономить оперативную память, упростив дочерние элементы элементов, которые находятся за пределами видимой области, но это далеко не тривиально. Однако на самом деле он использовал больше процессора, поскольку требовал много дополнительной работы.   -  person dtech    schedule 19.04.2017
comment
@KubaOber: я использую аппаратный рендеринг, но все еще имею проблемы с использованием ЦП. Обратите внимание, что у меня ~ 250 элементов, так что не так уж и мало.   -  person Stefan Monov    schedule 19.04.2017
comment
Представление списка сделает это автоматически и загрузит только те элементы, которые приближаются к видимой области, но там у вас есть модель в качестве базы данных. Без этого потребуется настраиваемая структура данных для хранения отбракованного материала, также требуется довольно много сопоставления координат, и у него есть недостаток — вы не можете отразить изменения, которые происходят с элементами, которые находятся в автономном режиме.   -  person dtech    schedule 19.04.2017
comment
Наконец, не зная реального сценария использования, практически невозможно предложить стратегию реализации. Элементы в представлении прокрутки могут быть самыми разными, от очень до неоптимизируемых...   -  person dtech    schedule 19.04.2017
comment
@dtech: Re: Элементы в представлении прокрутки могут быть разными: важно только то, что я могу установить для них visible: false, а затем снова true. Чтобы сэкономить на перекраске процессора. Обратите внимание, что я не пытаюсь сэкономить на оперативной памяти.   -  person Stefan Monov    schedule 19.04.2017
comment
Просто вычислите абсолютную позицию элемента относительно представления, и если он находится внутри отслеживаемой видимой области представления, включите, иначе отключите. Однако я не уверен, что настройка visible на false сама по себе принесет вам много пользы. Отслеживание и переключение видимости может в конечном итоге потреблять больше ресурсов ЦП.   -  person dtech    schedule 19.04.2017
comment
@dtech: Просто обновление по этому поводу: установка opacity: 0 для элементов за пределами области просмотра действительно выиграла меня. IIRC I перешел с 12% использования ЦП на 3,5% использования ЦП для 257 элементов, 21 из которых находится в области просмотра. Я думаю, что эксперименты, в которых я использовал visible: false, показали аналогичные улучшения.   -  person Stefan Monov    schedule 01.05.2017
comment
@StefanMonov - это хорошая новость, но странно, что у вас такая высокая загрузка ЦП. Мой проект легко обрабатывает 20 тыс. объектов, выложенных с помощью привязок в сложное дерево. На какое оборудование вы ориентируетесь? А может это предметы?   -  person dtech    schedule 01.05.2017
comment
@dtech: Измерения, которые я упоминаю, сделаны на моем собственном ноутбуке, который довольно хорош: см. характеристики. Вы действительно смотрели на использование вашего процессора, или вы предполагаете, что оно низкое, потому что у вас хорошая частота кадров? Обратите внимание, что моя частота кадров тоже хороша без отбраковки.   -  person Stefan Monov    schedule 01.05.2017
comment
@dtech: Также обратите внимание, что моя сцена перерисовывается со скоростью 60 кадров в секунду из-за одной анимации, которая постоянно работает со скоростью 60 кадров в секунду. Это правда в вашем случае?   -  person Stefan Monov    schedule 01.05.2017
comment
Просматривая 1000 объектов, каждый из которых состоит примерно из 15 отдельных элементов QML, я получаю около 5% загрузки ЦП. Но опять же, это на i7 с тактовой частотой 4,5 ГГц. Меня не волнует частота кадров, пока она не заикается. В конце концов, это древовидный редактор, и он отлично работает даже на моем устаревшем телефоне Note 3. Ключевым моментом здесь является то, что в моем случае ветви дерева могут быть свернуты, что является единственным разумным способом навигации по дереву, которое обычно состоит из 100 000 и нескольких миллионов объектов. Так что на практике подсчет объектов для меня не такая уж большая проблема, но я, тем не менее, подтолкнул его, чтобы увидеть, как работает QML, и он работает ПЛОХО :)   -  person dtech    schedule 01.05.2017
comment
Надеемся, что bugreports.qt.io/browse/QTBUG-67274 соберет обсуждение этой темы. в конце концов.   -  person Mitch    schedule 23.03.2018

Ответы (2)


arrow_upward
5
arrow_downward

Вот тривиальный пример, который вы можете расширить:

Window {
  visible: true
  width: 640
  height: 480

  Rectangle {
    anchors.centerIn: parent
    width: 200
    height: 200
    color: "yellow"

    Flickable {
      id: view
      anchors.fill: parent
      contentWidth: 200
      contentHeight: col.height
      property real span : contentY + height
      Column {
        id: col
        x: 90
        spacing: 2
        Repeater {
          model: 50
          delegate: Rectangle {
            width: 10
            height: 10
            color: inView ? "blue" : "red"
            property bool inView: y > view.contentY && y < view.span
          }
        }
      }
    }
  }
}

Очевидно, что полное доказательство также будет включать в расчет высоту элемента. Вы также можете сделать проверку по оси X, если это необходимо.

person dtech    schedule 19.04.2017
comment
Я бы сказал, что это должно быть y >= view.contentY && y + height <= view.span или y + height >= view.contenY && y <= view.span ;-) - person Amfasis; 17.03.2020

arrow_upward
0
arrow_downward

Чтобы добавить к ответу dtech, я только что узнал, что существуют компоненты QML, такие как GridView и ListView, которые автоматически отбирают.

person Stefan Monov    schedule 18.08.2017