Есть средства ускорить drawPoint ?, медленно выводятся точки Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Стандартный Переключить на: Линейный

[mezmay]

Захотел сделать удобное средство для вывода цифровых сигналов на график. Все бы ничего, только когда приходится отображать на виджете хотя бы 50.000 точек начинаются тормоза. Проверка на попадание точки в данный момент на график производится. Не понятно - как HD видео например на экран выводится? там же больше миллиона точек... или программа cool edit pro как отображает 10 млн точек без малейших тормозов? понятно, что она производит проверку на слияние и выводит только одну из всех слившихся, но все равно на экране вполне может оказаться больше 50.000 точек. Как вообще в таких случаях поступают?

вот мой пример. Здесь цикл по выводу точек на виджет с проверкой на попадание:

for(int i=0; i<data.size(); i++){            
            if(tx> left && tx < right && ty > bottom && ty < top)            
                painter.drawPoint(QPoint(tx + dx, -ty + dy));                
    }

[trdm]

Возможно лучшим вариантом будет не "painter.drawPoint"
что-то вроде
пиксмап.сетПиксель(...)
а потом
painter.драуПиксмап
Как считаешь, возможен такой выход?

[mezmay]

Возможно лучшим вариантом будет не "painter.drawPoint"
что-то вроде
пиксмап.сетПиксель(...)
а потом
painter.драуПиксмап
Как считаешь, возможен такой выход?

нет, так не быстрее. Но зато именно такой способ используют для того чтобы запоминать определенные положения графика и не перерисовывать его поточечно.

а по поводу кул эдита - там все по-хитрому сделано и 50.000 точек никогда не отображается. Если надо отобразить 10 миллионов точек, то вместо них рисуют 1024 "палки" (если разрешение экрана например 1024х768). Где в каждую "палку" входит очень много точек - набор из (10 млн/1024)точек. Нижняя и верхняя границы "палки" - это минимум и максимум из этого набора. Ну и эти самые минимум и максимум уже соединяются, например, QLine'oм. При масштабировании по оси х все это дело растягивается и количество точек в каждом наборе уменьшается. После определенного момента уже появляются сами точки.

В реальном времени 10 млн точек преобразовать в набор отезков нельзя, это происходит при открытии файла и занимает несколько секунд.

Но и это еще не все. Допустим, мы открыли файл с этими пресловытыми десятью миллионами точек (а на самом деле там каким-то чудом и гораздо больше спокойно отображается). Выделили где нибудь в середине, например, 3.567.123 точки и нажали "увеличить". Указанный диапазон мгновенно масштабируется. Как это происходит - я пока не понял) Хотелось бы услышать идеи.

[mezmay]

Вот пример отображения большого массива в виде палок:


а вот отмасштабированный кусок:

[Litkevich Yuriy]

Указанный диапазон мгновенно масштабируется.

картинка используется. Рисование осуществляется на картинке она масштабируется. А в фоне можно пытаться рисовать новую картинку, потом её отображать.

Я эксперементировал с примером painting\svgviewer, загружал 120 МБ SVG'шку, загружается не быстро, но масштабируется моментально.

[pirks]

Захотел сделать удобное средство для вывода цифровых сигналов на график. Все бы ничего, только когда приходится отображать на виджете хотя бы 50.000 точек начинаются тормоза. Проверка на попадание точки в данный момент на график производится. Не понятно - как HD видео например на экран выводится? там же больше миллиона точек... или программа cool edit pro как отображает 10 млн точек без малейших тормозов? понятно, что она производит проверку на слияние и выводит только одну из всех слившихся, но все равно на экране вполне может оказаться больше 50.000 точек. Как вообще в таких случаях поступают?

вот мой пример. Здесь цикл по выводу точек на виджет с проверкой на попадание:

for(int i=0; i<data.size(); i++){            
            if(tx> left && tx < right && ty > bottom && ty < top)            
                painter.drawPoint(QPoint(tx + dx, -ty + dy));                
    }

Может стоит выводить графики через QWT ?

[Cergey]

Вообще для работы с каждым пикселем используется класс QImage. Быстрее его уже нельзя!!!

[ufna]

Вообще, дело ведь в том, что рисовать нужно только то, что пользователь увидит. Т.е. отсчет ненужное изначально. А затем- правильно продумать КАК мы будем это рисовать. Кэширование, дв. буфф и т.п.

Имхо, сабж нужно повернуть в это русло, а не как убыстрить вывод 50к точек.

[pirks]

Вообще, дело ведь в том, что рисовать нужно только то, что пользователь увидит. Т.е. отсчет ненужное изначально. А затем- правильно продумать КАК мы будем это рисовать. Кэширование, дв. буфф и т.п.

Имхо, сабж нужно повернуть в это русло, а не как убыстрить вывод 50к точек.

Да что вертеть, если есть уже написанные и отлаженные модули по выводу графиков и диограм ))

[mezmay]

Вообще, дело ведь в том, что рисовать нужно только то, что пользователь увидит. Т.е. отсчет ненужное изначально. А затем- правильно продумать КАК мы будем это рисовать. Кэширование, дв. буфф и т.п.

Имхо, сабж нужно повернуть в это русло, а не как убыстрить вывод 50к точек.

ну, я в это русло и повернут) в вроде бы все принципиальные вопросы продумал... 50к уже не вывожу))

такой вопрос - если я использую в качестве контекста рисования картинку (на которой делаю drawLine, drawPoint, drawRect а потом ее рисую )- то какую картинку быстрее использовать? QImage или QPixmap ?