Большая часть производительного способа изобразить тысячи точек данных в виде графика с WPF?
Вы не можете программно установить стиль просмотра, но вы можете сделать что-то вроде textView.setTextAppearance(context, android.R.style.TextAppearance_Small);.
8 ответов
Я бы подумал о понижении дискретизации количества точек, которые вы пытаетесь визуализировать. У вас может быть 50 000 точек данных, но вы вряд ли сможете уместить их все на экране; даже если вы нанесли на карту каждую точку на одном экране, вам потребуется 100 000 пикселей по горизонтали, чтобы нарисовать их все! Даже в D3D много рисовать.
Поскольку у вас, скорее всего, будет что-то вроде 2048 пикселей, вы также можете уменьшить количество точек, которые вы графически отображаете, и нарисовать приблизительную кривую, которая умещается на экране и имеет всего пару тысяч верт. Если, например, пользователь отображает временной интервал, включающий 10000 точек, то перед построением графика уменьшите эти 10000 точек до 1000. Вы можете попробовать множество техник, от простого усреднения до медианного соседа и свертки по Гауссу до (мое предложение) бикубической интерполяции . Рисование любого количества точек, превышающих 1/2 разрешения экрана, будет просто пустой тратой .
Когда пользователь увеличивает масштаб части графика, вы можете выполнить повторную выборку, чтобы получить более высокое разрешение и более точную подгонка кривой.
Когда вы начинаете иметь дело с сотнями тысяч различных вершин и векторов в своей геометрии, вам, вероятно, следует подумать о переносе графического кода для использования графической структуры вместо зависимости от WPF (который, хотя и построен поверх Direct3D и, следовательно, может замечательно эффективный рендеринг векторной графики, имеет много дополнительных накладных расходов, что снижает его эффективность). В WPF-I можно разместить окна рендеринга графики Direct3D и OpenGL.
Я считаю, что единственный метод, который может быть быстрее, оставаясь в рамках WPF, - это переопределить OnRender в настраиваемом элементе управления. Затем вы можете визуализировать свою геометрию прямо в постоянной сцене, убирая все из поля зрения. Если пользователь может видеть только небольшую часть набора данных за раз, отбраковки может быть достаточно само по себе.
С таким большим количеством точек данных маловероятно, что пользователь сможет увидеть полную информацию, когда весь набор данных находится в поле зрения. . Так что, возможно, также стоит подумать об упрощении набора данных для полного просмотра, а затем показать более подробный вид, если и когда они увеличиваются.
Изменить: Кроме того, попробуйте StreamGeometry. Вся причина его существования - производительность, и вы никогда не узнаете, пока не попробуете.
Я не работал с WPF (отказ от ответственности), но подозреваю, что ваша проблема с производительностью связана с тем, что ваш код пытается провести гладкую изогнутую линию через все ваши данные, и требуется время геометрически (или хуже) увеличивается с увеличением числа точек данных.
Я не знаю, будет ли это приемлемым с точки зрения внешнего вида, но попробуйте изобразить данные, соединив каждую точку с последней прямой линией. Это должно сделать время построения графика пропорциональным количеству точек данных, и с таким количеством точек, сколько у вас есть, график в любом случае может выглядеть точно так же.
Это очень хороший вопрос, и, по сути, напрашивается вопрос: «Может ли любой пользователь на практике использовать экран, содержащий 100 000 дискретных точек, или делать из него бизнес-решения?»
Следуя передовой практике в философии проектирования графических интерфейсов, ответ должен быть Нет , что заставило бы меня задаться вопросом, нет ли другого способа удовлетворить требование для приложения.
Если действительно существует добросовестный случай отображения 100 000 точек на экране без прокрутки, тогда используйте закадровый буфер - лучший вариант. Скомпонуйте свое изображение в растровое изображение, а затем вставьте это растровое изображение в окно / страницу по мере необходимости. Таким образом, подъем тяжестей выполняется только один раз,
Я не знаю, насколько хорошо он масштабируется, но я добился определенного успеха, используя ZedGraph в WPF (элемент управления WinForms внутри WindowsFormsPresenter). Я удивлен, что никто об этом еще не упомянул. На него стоит взглянуть, даже если вы не планируете использовать его в своем текущем проекте.
Удачи!
Только что столкнулся с этим вопросом, но, как я уже упоминал в этом потоке, наиболее эффективным подходом может быть программирование с использованием визуального уровня WPF .
Все визуальное в WPF в конечном итоге противоречит этому уровню ... и поэтому это самый легкий подход из всех.
См. this и this для получения дополнительной информации. В главе 14 книги Мэтью Макдональда Pro WPF в C # 2008 также есть хороший раздел.
В качестве еще одной ссылки ... см. Главу 2 книги Павана Подилы WPF Control Development Unleashed ]. На странице 13 он обсуждает, как DrawingVisuals может стать отличным выбором для графического компонента.
Наконец,
Еще одна идея - использовать элемент управления Image со свойством Source, для которого установлено значение DrawingImage, которое вы динамически создали.
Согласно Павану Подила в ] WPF Control Development Unleashed , этот подход может быть очень полезным, когда у вас есть тысячи и тысячи визуальных элементов, которые не нуждаются в интерактивности. Дополнительную информацию можно найти на странице 25 его книги.