Передача данных

[AHDPE@ich]

Есть некий код, позволяющий отправлять файлы с одной машины на другую по сети. Конкретно, передается картинка. Фотографируется рабочий стол, сохраняется как jpeg, затем картинка с помощью Winsock перетекает на другой компьютер, где также сохраняется в файл, и только потом открывается и отображается на форме. процесс растянулся из-за постоянной работы с жестким диском. как сделать, чтобы данные из одного PictureBox на первом компе пересылались на второй в приложение, а затем сразу отображались?

[FireFenix]

Image -> сериализация в Byte() -> Winsok -> десиаризация Byte() -> Image -> PictureBox -> profit

картнка -> Byte() можно через GetBitmapBits или через замут с PropertyBag

[AHDPE@ich]

Так, с GetBitmapBits разобрался. Теперь, как я понимаю, "десериализацию" надо сделать через SetBitmapBits? Но PictureBox как был чистым, так и остался... да и попробовал записать на диск содержимое массива, вышло порядка 6 мегабайт, довольно много для передачи

[AHDPE@ich]

с PictureBox'ом разобрался, все отлично. Но размер переменной оставляет желать лучшего

[FireFenix]

Ну дык, непожатая картинка... Перед отправкой сжимай или кодируй в jpeg,png и после получения - обратно

[AHDPE@ich]

как это несжатая...она изначально грузится из jpg файла.

[FireFenix]

:shock: как это несжатая...она изначально грузится из jpg файла.

То что она грузиться из jpeg - это не значит, что она в памяти лежит как jpeg

jpg, png, tiff, etc -> bmp -> picturebox.picture -> bmp -> jpg, png, tiff, etc

[AHDPE@ich]

все, понял, спасибо. переконвертировал bmp в jpg

[Хакер]

И радуется. Что-ж тут хорошего? Худший выбор.

[AHDPE@ich]

посоветуйте вариант лучше? для расширения кругозора хотя бы

[FireFenix]

Передавать изображение только изменённой части рабочего стола, а не всего
Использовать формат сжатия без потери качества... типа png...

[AHDPE@ich]

сжатие пятидесятипроцентное, неплохо видно. наверное, критика касалась чего-то другого

[Хакер]

Критика касалась использования сжатия с потерями (которое отпатимально для фотографий), вместо PNG-подобного (которое оптимально для окон и скриншотов).

А ещё критика касалась самой идеи передачи картинки вместо передачи GDI-команд.

[AHDPE@ich]

А ещё критика касалась самой идеи передачи картинки вместо передачи GDI-команд.

подробнее можно?

[AHDPE@ich]

Прочел топик
viewtopic.php?f=1&t=32664&start=0&st=0&sk=t&sd=a

стало более-менее понятно насчет GDI-команд
сразу вопрос: насколько сложно реализовать передачу команд и их обработку?

[Хакер]

Откуда я знаю, насколько лично тебе это сложно?

[AHDPE@ich]

ну да, согласен. некорректный вопрос... тогда так: где можно почитать про основы работы с GDI?

[FireFenix]

http://www.google.ru

Можно попробовать обычное рисование массива, которое можно посмотреть здесь viewtopic.php?t=30324 (предпоследний пост)

[Хакер]

где можно почитать про основы работы с GDI?

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

рисование массива можно посмотреть здесь viewtopic.php?t=30324 (предпоследний пост)

А это не нужно для подхода с передачей команд.

[FireFenix]

А ещё критика касалась самой идеи передачи картинки вместо передачи GDI-команд.

Немного нубский вопрос...

Рационально ли вообще передавать GDI команды?
Поидее ведь после запуска некоторого количества приложений, которые рисуются на экране - объём GDI сообщений будет превышать объём сжатой картинки изменённой части экрана
Или если рисуется сложная композиция из полигонов заполняемых растром с альфой, то трафик может быть равен или даже превышать трафик картинки

Не?

[Хакер]

Нет.

Во-первых, GDI команды вызывают не от нефиг делать, а по запросу валидации инвалидированной области. Ну или в случае анимации. Если ничего не происходит, то никаких GDI-команд нет.

Потом, например, сдвинули мы окно из одного места в другое. Или прокрутили что-то прокручивающееся. Изменения имеют место быть. Работая с видом как с картинкой вычислить такие изменения довольно сложно (без анализа образов — практически невозможно).

А с точки зрения GDI-команд сдвиг окна или прокрутка какой-то области — это всего лишь вызов ScrollWindowEx. Надо транслировать его, и прокрученная часть просто сдвинется на целевой машине.

Иными словами, смотри:
а) Передать информацию «сдвинуть такой-то прямоугольный растр в такое-то новое место». Это 6 параметров.
б) Иметь две картинки и пытаться каким-то неведомым образом сравнивая их — определить, какие прямоугольники и куда были сдвинуты. Максимум, что можно легко вычислить — какие многоуольники изменились. И передавать изменённые данные. Это значит, что будут заново переданы все сдвинутые хоть на 1px точки, несмотря на то, что все эти точки, вернее информация о них уже есть на целевой машине.

Что касается изменений вообще: это либо сдвиги и копирования (Blt-функции), либо простая геометрия (перья и кисти), либо рисование предзагруженных ресурсов (иконок, битмапов и т.д.). Гораздо лучше вместо передачи изменений хранить информацию обо всех этих сущностях (созданных кистях, перьях, загруженных иконках, битмапах) на целевой машине и рисовать ими там же (на целевой).

[FireFenix]

Насчёт количества сущностей я наверное преувеличил... пока не встречал приложений камикадзе, где на каждый пиксель - сущность...
И насчёт операций над сущностями - тоже верно!

Но если возьмём рабочий стол с обоиной и будем показывать полупрозрачную форму (в которой 90% места занимают картинки/значки), то нам нужно будет передать картинку рабочего стола, картинки ярлычков раб.стола и прямоугольник/регион формы со всеми его сущностями
В этом случае поидее должно передаться больше информации... Наверное это также касается Aero, хотя может оно работает и по другому

И как я понимаю, при передачи GDI команд, в приложениях типа видео-плеера, игр, 3д редакторов и т.д. работающих с DirectX, OpenGL мы получим квадрат малевича?

И ещё интересно, вроде как WPF (собсно VS её использует) приложения сразу рисуют через DX, то при просмотре таких приложений мы тоже ничего не увидим?

[Хакер]

В этом случае поидее должно передаться больше информации...

Откуда больше информации-то?

И как я понимаю, при передачи GDI команд, в приложениях типа видео-плеера, игр, 3д редакторов и т.д. работающих с DirectX, OpenGL мы получим квадрат малевича?

Вероятно.

И ещё интересно, вроде как WPF (собсно VS её использует) приложения сразу рисуют через DX, то при просмотре таких приложений мы тоже ничего не увидим?

Ну так если идиотизм царит в новом поколении решений от MS, тут хоть плачь, хоть смейся, — ничего не поделаешь.

Но и с DX есть выход: перехватывать DX-общения и транслировать их на целевую машину и выполнять над созданным там DX-устройством.

С OpenGL всё гораздо лучше: там грамотная архитектура, которая заранее предусматривает, что GL-команды (официальный термин, прошу заметить) вызываются на одной стороне, а выполняются — на другой. Более того, там GL-команды могут записываться в списки, списки могут вызываться как одна команда, а вызовы списков могут быть записаны в другие списки. Если приложение грамотное и написано с использованием списков, то тут всё очень позитивно: GL-трафик будет минимальный.

[FireFenix]

В этом случае поидее должно передаться больше информации...

Откуда больше информации-то?

Возьмём:
Рабочий стол 1024*768 (полное растягивание обоины)
10 Ярлычков 64*64
Форма 300*300 в которой 6 ярлычков 64*64

Юзер из фуллскрина выходит на рабочий стол с полупрозрачной формой...

Взяв грубо (без учёта Пуск и других плюшек), получилось:

GDI Комманды, т.е. контент сущностей GDI:
1) Сущность 1024*768 ~ 786к пикселей
2) 10 cущностей 10*64*64 ~ 41к пикселей
3) Форма с 6ью сущностями 6*64*64 ~ 25к пикселей
Суммарно = 786к + 41к + 25к = 852к пикселей
RGBA 32bit = 852к * 4 = 3408 Кб ~ 3,5Мб

Фреймы:
Целая картинка RGBA 32bit 1024*786*4 ~ 3,14Мб (Почти число пи )
Но т.к. на не нужна альфа, мы можем использовать RGB 24bit 1024*768*3 ~ 2,36 Мб
32bit PNG из 2,36Мб дало 1,08Мб

Не знаю, сжимает ли GDI растр при передаче... но итого мы получили GDI 3.5Mb против Фреймов 2,36Мб -> 1,08Мб

Я не прав?

Т.е. у GDI пиковая загрузка канала выше, но половины работы загрузка канала в минмуме, когда у фреймов почти одинаковый поток всё время и на прилично ниже пиковой GDI

Но и с DX есть выход: перехватывать DX-общения и транслировать их на целевую машину и выполнять над созданным там DX-устройством.
С OpenGL всё гораздо лучше: там грамотная архитектура, которая заранее предусматривает, что GL-команды

Ну тут ведь тоже ресурсозатратно, мало того что нам надо уже перебросить 3х мерные каркасы, текстуры, шейдеры... Так нам нужно ещё и железо способное обработать

Поидее пересылка фреймов должна быть выгоднее

[Хакер]

Ну у тебя фреймы передаются каждый раз, а у меня сущности — единожды.

Да и что за ярлыки 64×64 при таком разрешении?