![]() |
Серверный скриншот SWF-файла
Вопрос, вроде, в этом разделе ещё не поднимался...
Задача волнует многих в сети, но более-менее приемлемого решения пока не нашёл. А заключается она в том, что нужно на сервере получить высококачественный JPEG (quality 80) на стороне сервера, снятый с какого-либо обьекта во Flash'e на стороне клиента. Обьект, который нужно заснять, представляет собой контейнер с обьектами, которые может разбрасывать пользователь. Самое распространённое решение: [BitmapData -> JPEGEncoder -> ByteArray -> пересылка на сервер с помощью, к примеру, AMF] В принципе неплохо, но есть два больших недостатка - сильно загружается процессор и канал при сохранении картинок большого размера (близкого к 3000х3000). В принципе, можно передавать на сервер XML с положениями всех обьектов, которые разбросал по сцене пользователь, но тогда на серверной стороне нужно восстановить сцену, подождать, пока загрузятся всеобьекты и каким-то образом снять скриншот с неё. В сети существуют различные решения для этого, но почти все они по сути используют ActiveX-компонент, который, как я понимаю, доступен только под Windows. Известно ли какое-либо решение для Linux-платформ? Узнавал в сторону AIR, но он не поддерживаем Linux... |
а как, пардон, происходит "восстановление сцены" в общих чертах?:confused:
|
К примеру, на клиентской стороне пользователь кладёт на сцену обьекты, которые представляют собой загружаемые извне SWF-файлы. На сервер передаются данные о координатах этих обьектов на сцене. На серверной стороне существует другая флешка, которая принимает эти данные и размещает аналогичные обьекты в тех же координатах.
|
Я хочу заметить. что ни флэш, ни мониторы разрешения 3000*3000 не тянут. И вы как считаете - если на сервере из восстановленной сцены делать скриншот, то процессор загружаться небудет? Я сильно сомниваюсь.
|
2 †‡Paladin‡†:
> ни флэш, ни мониторы разрешения 3000*3000 не тянут Я передаю на сервер JPG-файл, снятый с DisplayObject'а размером около 2400х1700 пикселей. Разрешение монитора значения не имеет. Флеш данными такого обьёма оперировать может. > И вы как считаете - если на сервере из восстановленной сцены делать скриншот, то процессор загружаться небудет? Будет, но если это делать не средствами Флеша, то результат может выйти не таким плачевным, как вам кажется. |
а 3000 на 3000 уже неможет. в любом случае вам надо будет запускать swf на сервере и снимать скриншоты, при том, что можно легко это забодяжить на c++, загруженный swf будет занимать память и отнимать ресурсы сам по себе. Лично мне непонятно почему нельзя повесить этот геморрой на машину клиента. кроме нескольких секунд работы проца и исходящего трафика он ниче не теряет. Танцы с бубном излишни.
|
Цитата:
|
Цитата:
|
2 †‡Paladin‡†:
Время покажет. ^_^ На ваше чутьё я бы не полагался... У наших клиентов комьютеры не настолько слабые, а вот у клиентов наших клиентов - Бог знает. Я сегодня попробую устроить бенчмарк на разных компьютерах. Может потом выложу результаты... |
>>Узнавал в сторону AIR, но он не поддерживаем Linux...
т.е. для вас не принципиально в браузере флэш или в оболочке? |
Цитата:
|
2 alexcon314:
Да. Под Windows я бы написал серверное консольное приложение на Delphi или C++, которое запускает флешку в ActiveX-компоненте, восстанавливает сцену с нужными размерами, созданную пользователь, снимает с канвы компонента битовое изображение, кодирует в JPEG и сохраняет. Цитата:
Я работаю с Flash-платформой не первый год и прекрасно знаю, на что оно способно, а на что - нет. Собственно, результаты говорят о том, что я был прав. P4 1.8GHz 1.00 Gb RAM ============== 11s - quality:60 | dpi:150 | format:A5 35s - quality:60 | dpi:300 | format:A5 9s - quality:70 | dpi:150 | format:A5 33s - quality:70 | dpi:300 | format:A5 9s - quality:80 | dpi:150 | format:A5 34s - quality:80 | dpi:300 | format:A5 5s - quality:60 | dpi:150 | format:A6 17s - quality:60 | dpi:300 | format:A6 5s - quality:70 | dpi:150 | format:A6 17s - quality:70 | dpi:300 | format:A6 5s - quality:80 | dpi:150 | format:A6 17s - quality:80 | dpi:300 | format:A6 AMD Athlon XP 2100+ (1.73 GHz) 512 MB ============== 5s - quality:60 | dpi:150 | format:A5 17s - quality:60 | dpi:300 | format:A5 5s - quality:70 | dpi:150 | format:A5 18s - quality:70 | dpi:300 | format:A5 5s - quality:80 | dpi:150 | format:A5 16s - quality:80 | dpi:300 | format:A5 2s - quality:60 | dpi:150 | format:A6 8s - quality:60 | dpi:300 | format:A6 3s - quality:70 | dpi:150 | format:A6 11s - quality:70 | dpi:300 | format:A6 3s - quality:80 | dpi:150 | format:A6 8s - quality:80 | dpi:300 | format:A6 Core2 1.6GHz 1Gb DDRII ============== 5s - quality:60 | dpi:150 | format:A5 16s - quality:60 | dpi:300 | format:A5 3s - quality:70 | dpi:150 | format:A5 11s - quality:70 | dpi:300 | format:A5 3s - quality:80 | dpi:150 | format:A5 12s - quality:80 | dpi:300 | format:A5 2s - quality:60 | dpi:150 | format:A6 6s - quality:60 | dpi:300 | format:A6 2s - quality:70 | dpi:150 | format:A6 12s - quality:70 | dpi:300 | format:A6 2s - quality:80 | dpi:150 | format:A6 6s - quality:80 | dpi:300 | format:A6 AMD 2.41GHz 1Gb ============== 3s - quality:60 | dpi:150 | format:A6 8s - quality:60 | dpi:300 | format:A6 4s - quality:70 | dpi:150 | format:A6 8s - quality:70 | dpi:300 | format:A6 2s - quality:80 | dpi:150 | format:A6 8s - quality:80 | dpi:300 | format:A6 4s - quality:60 | dpi:150 | format:A5 15s - quality:60 | dpi:300 | format:A5 5s - quality:70 | dpi:150 | format:A5 15s - quality:70 | dpi:300 | format:A5 4s - quality:80 | dpi:150 | format:A5 17s - quality:80 | dpi:300 | format:A5 P4 1.8GHz 512 RAM ============== 9s - quality:60 | dpi:150 | format:A5 26s - quality:60 | dpi:300 | format:A5 7s - quality:70 | dpi:150 | format:A5 28s - quality:70 | dpi:300 | format:A5 7s - quality:80 | dpi:150 | format:A5 27s - quality:80 | dpi:300 | format:A5 4s - quality:60 | dpi:150 | format:A6 14s - quality:60 | dpi:300 | format:A6 4s - quality:70 | dpi:150 | format:A6 14s - quality:70 | dpi:300 | format:A6 4s - quality:80 | dpi:150 | format:A6 14s - quality:80 | dpi:300 | format:A6 |
>> Под Windows я бы написал серверное консольное приложение на Delphi или C++, которое запускает флешку в ActiveX-компоненте, восстанавливает сцену с нужными размерами, созданную пользователь, снимает с канвы компонента битовое изображение, кодирует в JPEG и сохраняет.
это новое слово в технологии, имхо. возможно, это кто-то уже делал, не в курсе. меня интересует вопрос о локальном сохранении графической информации из флэша. но сам подход и здесь видится в том же духе: СТОРОННЕЕ приложение снимает графику с выводом в файл.. короче говоря, вы видите какие-либо альтернативы? |
Цитата:
Локальное сохранение? Просто методами Флеша или Флекса нельзя, потому что файлы писать из таких приложений нельзя. Можно, наверное на AIR или с Zinc'ом. А стороннее приложение я написал уже на Delphi. Глючит немного, но скриншоты делает. |
>> Можно, наверное на AIR или с Zinc'ом. А стороннее приложение я написал уже на Delphi. Глючит немного, но скриншоты делает.
с цинком понятно, аир не пользовал, но наверно не совсем он под это дело заточен. если не секрет, поподробнее о вашем приложении можно? это ехе с встроенным плеером? или оно как-то взаимодействует с флэшем в браузере? |
2 alexcon314:
Ну, под Windows флешки обычно отрисовываются ActiveX-компонентом. Этот ActiveX-компонент никто не мешает использовать в приложении. ^_^ В него можно легко загрузить флешку. |
Цитата:
|
2 †‡Paladin‡†:
Не стоит иронизировать. ^_^ К тому же вы как-то избирательно читаете сообщение. Я привёл результаты бенчмарка. |
Цитата:
|
Я бы покопал в сторону svg файлов. Кроме того в инете есть векторизатор jpg.
|
Цитата:
|
Рисовалку визиток/календариков делаешь? Эх, такой проект ушел у меня из под носа...
А снять скриншот легко. Открываешь в браузере свою флешку, дожидаешься отрисовки (хоть по таймеру, хоть флешка сама подаст сигнал), потом export-ом снимаешь скриншот, подрезаешь, convert-ом или еще чем-то сохраняешь в свой любимый jpeg... Разрешение любое, хоть 10000х10000, только бы сам флеш потянул, да памяти хватило. А память кушается сильно. Если на сервере нету иксов, то можно запустить их эмуляцию, например, xvnc. Дабы браузер знал, где ему рисовать свои окна, то в скрипте запуска установи переменную DISPLAY (заглавными буквами), присвой ей номер экрана, с которого потом будешь хватать... Так хватать можно чего угодно, хоть флеш, хоть скриншоты сайтов, хоть чего. |
2 LinuxVideo:
Угу, что-то вроде такой рисовалки. ^_^ Решение с броузером гуляет по сети, но я не стал на него обращать внимание. Запускать броузер всего лишь для скриншота - это действительно сильно жестоко для сервера. К тому же в своей программе наиболее грамотно можно дождаться загрузки всех ресурсов во флешку, а потом "пнуть" программу из флешки. |
> Запускать броузер всего лишь для скриншота - это действительно сильно жестоко для сервера.
Ну не так уж и жестоко... А у тебя есть выбор? > К тому же в своей программе наиболее грамотно можно дождаться загрузки всех ресурсов во флешку, а потом "пнуть" программу из флешки. Так и пни. Открой сокет до сервера, скрипт выполнит скриншот в нужный момент. |
2 LinuxVideo:
Да. Выбор есть. Такой, как я писал выше. |
Мне интересно, как это запускать собрались?
|
2 LinuxVideo:
Что? Флешку? ActiveX-компонентом. |
| Часовой пояс GMT +4, время: 02:00. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.