Узок их круг, страшно далеки они от народа
Кросспост из блога автора. Комментировать лучше там, но можно и тут
Вот берем Qt 5.1, тащим на Mac OS X 10.7 (так сложилось, это моя девелоперская машина), собираем согласно инструкции.
Далее собираем приложение с этой Qt, деплоим его тоже по инструкции, несем на Mac OS X 10.6 и получаем, получаем... сюрприз:
Неработающее приложение!
То что ( Read more... )
В смысле написан.
> Как мне получить этот объект "внутри" яваскрипта?
Никаки. Связка между JS и C++ примерно на уровне SQL и C++. С++ объект внутри SQL не получают.
> Ну там скормить ему файл, подождать пока прожует, потом он выплюнет 400 мегабайт (например) RGB-битмепа
JS узнаёт у юзера имя файла и передает его C++. С++ жуёт. Когда прожевал - вызывает, например, OpenGL, если хочется экстрима.
> Сгенерировать JPEG и скормить его этому CEF-у? Херня же какая-то....
И так тоже можно. Только не JPEG конечно, а loseless PNG. Я бы именно так и сделал, и всё верчение-зуменье засунул в JS, типа такого:
http://demo.leadtools.com/HTML5/ViewerDemo.htm
> У меня приложение для быстрого жевания гигабайтов фоточек.
Ну и жуй себе, внутри C++. А потом отдавай простым UI-шны средствам для показа юзеру. Мы в 21-м веке, сейчас это визуалбейсиковая задачка - показать на экране двухмерную картинку сжатым размером ну пусть даже 60 мегабайт (на самом деле небось 16, да?). Делать надо через визуалбейсик, т.е. JS, canvas и WebGL как самый максимум. WebGL уже очевидно оверкилл для показа двухмерных картинок, но если надо извращений...
Reply
Что потеряю - выше написано (в перечислении того, что я беру из Qt). Thread pool, Map/Reduce, общий одинаковый и работающий интерфейс к OpenGL, много всего.
Reply
Ты выиграешь уплывание существенной части твоего продукта в очень высококачественную живую среду (HTML и CEF) из фиговатой и умирающей (Qt).
> обсуждать lossless PNG, имелся в виду, вероятно, нежатый, я не хочу
Имелся ввиду именно lossless. PNG сжимает внутри себя deflate-ом от zip-а. Непонятно, почему именно его ты не хочешь обсуждать, отличный формат для внутреннего обмена.
> Что потеряю - выше написано (в перечислении того, что я беру из Qt). Thread pool, Map/Reduce, общий одинаковый и работающий интерфейс к OpenGL, много всего.
Как-то ты это всё очень детально обсуждаешь, я бы даже сказал серьезно. Обычно когда человеку советуют выбросить нах глюкавый M$ Виндоуз и перейти на правильный кошерный Линукс ответ бывает короче и конкретнее.
Понятно что менять в живой программе базовую UI+ библиотеку на что-то совершенно другое как самый минимум очень лень.
Reply
Потому что сжать, чтобы тут же, через долю секунды, разжать - просто глупо. Я не хочу делать глупо, у меня вот есть готовая текстура, дайте мне PBO и я ее туда нагажу.
> Как-то ты это всё очень детально обсуждаешь, я бы даже сказал серьезно
Да, естественно. Потому что есть планшеты и прочие телефоны, где HTML5 - довольно натуральный путь.
Но на них эффективность еще важнее, чем на нормальном компьтере и идея кидаться внутри приложения жатыми PNG меня пугает.
Reply
Если через долю секунды - то не глупо, а пофигу.
Глупо если это медленно.
> Но на них эффективность еще важнее, чем на нормальном компьтере и идея кидаться внутри приложения жатыми PNG меня пугает.
Интуиция подсказывает мне, что в 21-м веке абсолютно любые операции, которые ты проделываешь с одиночной статической картинкой фотоаппаратного размера, выполняются за нулевое время на любом процессоре, включая телефонный.
Reply
Полгига запаковать zip-ом - это сколько?
> Интуиция подсказывает мне
Интуиция обманывает тебя.
Типичное время обработки (распаковки, преобразования, показа) "картинки фотоаппаратного размера, но не JPEG" - 2-4 секунды.
Что невероятно много, когда этих картинок - тысячи. А JPEG - не всех устраивает (и именно в эту группу я и целюсь своим софтом).
А смешнее всего то, что почти все "производители мелкой и средней руки" (но не Adobe) пользуются для этой "распаковки, преобразования" - одним и тем же кодом.
Reply
А вот известно сколько. Берем 229-мегабайтный нежатый Tiff и делаем:
$ time tiff2png 0.IIQ.tiff
real 0m43.362s
user 0m42.745s
43 секунды, короче. 5 мегабайт в секунду. Жмется в два раза.
Это: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
libpng у нас в природе одна, других не носят.
Вот и ответ на вопрос "быстро ли это..."
Reply
Тут в одном закрытом чатике обсуждают проблему визуализации большого количества данных. Как раз на HTML5/js
Так вот, пишут, что 25 мегабайт json распарсить - уже проблема, кровь-кишки-распидарасило.
И я, отчего-то, не удивлен.
Reply
Я думаю убивать без суда и следствия надо начинать на уровне трёхкилобайтного json-а. А за 25 мегабайтный надо перед смертью пытать несколько недель.
Это примерно как сделать SQL-ную таблицу с двумя миллионами полей.
Reply
Но за сжатие данных для передачи их в фронтенд для визуализации *внутри одного приложения* полагается ровно оно же.
Вместе с тем, если ты считаешь, что пользователю не впадлу поаплоадить полгигабайта прежде чем начать работать - я это учту. Есть у меня идея приложения за которое платить per use будут охотнее, чем покупать. Потому что нужно не каждый день.
Reply
Хранить легкосжимаемые данные в сжатом виде внутри программы - нормально.
Если у меня есть огромная картинка, и я никогда не показывать от неё юзеру больше маленького кусочка, нафига она мне вся такая расжатая постоянно в памяти?
> Вместе с тем, если ты считаешь, что пользователю не впадлу поаплоадить полгигабайта прежде чем начать работать - я это учту.
Нормальный домашний юзер с видеокамерой редко снимает ролики дольше трёх минут (собственно он редко снимает ролики дольше 40 секунд), и обычно он их хочет в итоге залить на Ютуб. Go figure.
"Вход на Ютуб с редактированием" - очень разумный сценарий приложения.
Reply
Чтобы поскроллить ее и позумить быстро. Ну и память же надо куда-то девать, а то понакупили 64-битных систем...
Мне, кстати, сдается, что ты никогда до OpenGL-я не доходил. Я сам дошел где-то с год назад и до сих пор в изумлении, то что у меня в одной программе делает изрядно кода (скажем, ~1000 строк, потому что параллельно и все такое) - делает теперь (в дпугой программе) 20-строчный шейдер. Цена вопроса - чипсетные интелы с OpenGL 1.5, но таких уже крайне мало (и есть, в принципе, эмулятор на DX9)
Reply
>
>Чтобы поскроллить ее и позумить быстро. Ну и память же надо куда-то девать, а то понакупили 64-битных систем...
Если стоит задача куда-то девать память, можно сделать PNG с нулевым сжатием.
> Я сам дошел где-то с год назад и до сих пор в изумлении, то что у меня в одной программе делает изрядно кода (скажем, ~1000 строк, потому что параллельно и все такое) - делает теперь (в дпугой программе) 20-строчный шейдер.
Теперь осталось сделать всё то же самое WebGL-ем, и будет совсем хорошо.
Reply
Leave a comment