Объем памяти SVG для сложной страницы - PullRequest
0 голосов
/ 12 февраля 2011

У меня есть дизайн, который требует большого количества маленьких гистограмм (размер спарклайна).Типичная страница может легко иметь более 60 графиков, показывающих более 100 точек данных на график.Будет ли использование памяти в браузере чего-то подобного недопустимым?Я также мог бы использовать рендерер на стороне сервера, который выводит pngs, но, похоже, гораздо больше можно сделать с SVG.

Другие соображения: SVG, вероятно, будет превращен в VML для IE Rapheal.js.Таким образом, объем памяти должен быть разумным.

Любая помощь или методология для поиска хорошего ответа приветствуется.

Ответы [ 3 ]

4 голосов
/ 18 февраля 2011

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

В отличие от элемента canvas, SVG требует, чтобы браузер поддерживал объектную модель для всех представленных элементов. Эта объектная модель позволяет легко связать событие с щелчком по конкретному элементу. Вам не нужно отслеживать, где находится квадрат на экране, насколько он велик, масштабировать и т. Д. Однако это связано с ценой требований к памяти и резко контрастирует с тегом canvas, который просто беспокоит о том, каким цветом рисовать пиксели, и вам нужно беспокоиться о том, чтобы отслеживать, на каком «объекте» щелкнули.

Итак, при попытке выяснить, будет ли проблема с производительностью, обычно разумно начинать с наименьшего общего знаменателя, так сказать, с точки зрения целевого оборудования. Вы нацеливаетесь на мобильные устройства? Вы ориентируетесь на ноутбуки и десктопы?

Получив ответ на этот вопрос, создайте фиктивное приложение, предназначенное для этого оборудования, которое использует один фиктивный граф (100 точек данных) снова и снова 60 раз. Создайте ровно столько, чтобы вы могли взаимодействовать с дисплеем таким образом, чтобы это отражало то, как ваши пользователи будут взаимодействовать с ним (если вы хотите, чтобы пользователи могли перемещать графики, это должно быть включено и т. Д.)

Используя этот упрощенный прототип, попробуйте использовать базовое взаимодействие, и если производительность соответствует вашим требованиям (то есть ожиданиям аудитории вашего приложения).

Что касается повышения производительности приложения такого рода, я бы предложил использовать комбинацию ajax и svg. Я генерировал бы эскизы графиков (используя SVG, они были бы намного меньше, благодаря уменьшенной детализации), и, поскольку пользователь решил получить больше деталей, я бы использовал ajax, чтобы получить более детальное представление SVG для этого конкретного граф.

Наслаждайтесь созданием своего приложения:)

1 голос
/ 28 февраля 2011

Идея Love Adam об использовании замены PNG для SVG-спарклайнов и сносе SVG по мере необходимости.Их можно легко отрендерить на стороне сервера, используя тот же источник SVG, который подается в библиотеку, например librsvg или, может быть, Cairo .

Если вы ищете что-токоторый использует canvas (с автоматическими обходными путями для IE), взгляните на библиотеку jQuery Sparklines , она может уже сделать все, что вам нужно.

0 голосов
/ 11 октября 2017

Нормализация ваших данных является ключевой.В большинстве случаев 100 точек данных не нужны и не заметны человеческому глазу в искровой линии шириной 50 пикселей.Используйте нормализацию данных, чтобы уменьшить значение со 100 до 5, что проще для глаз и более производительно.

Спрайты изображений на стороне сервера со спарклайном будут иметь тенденцию превосходить внешние сплайны, генерируемые SVG / Canvas, при большихих число.

Вот быстрое серверное спарклайн-решение в Java, которое использует отличное сжатие PNG:

https://github.com/AnthumChris/anthum-sparkline

...