Узок их круг, страшно далеки они от народа
Кросспост из блога автора. Комментировать лучше там, но можно и тут
Вот берем Qt 5.1, тащим на Mac OS X 10.7 (так сложилось, это моя девелоперская машина), собираем согласно инструкции.
Далее собираем приложение с этой Qt, деплоим его тоже по инструкции, несем на Mac OS X 10.6 и получаем, получаем... сюрприз:
Неработающее приложение!
То что ( Read more... )
Qt два раза рассматривал, честно. По-моему он какой-то бесполезный, особенно в свете нынешней живости CEF.
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
Кстати зря тебя вебовость совершенно не волнует. Не знаю как ты продаешься, может тебе это и не надо, но многие шараваршики верят сейчас в бесплатные онлайновые версии как в святой грааль.
OCR-ы вон онлайновые делают. Видеоредакторы.
Reply
Вопрос: а юзер этого безумия - кто?
Reply
Это какие-то странные слова - CinemaDNG, mpeg... Загрузите .mts, получите .flv.
А ещё лучше - получите URL на ютубе.
> залейте на сайт за недельку
Ютубу это расскажи, про "за недельку". Сегодняшний миллиард новых ютубовских роликов начал аплоадится 4-го августа, бгг.
> Вопрос: а юзер этого безумия - кто?
Кто юзер онлайновых версий программ? Да все. Вот я например.
Reply
Ну вот полчаса в HD с приличным качеством - это сколько гигов .mts?
> Кто юзер онлайновых версий программ? Да все. Вот я например.
В смысле - ты сам, лично, без ансамбля, пользуешься онлайн-версиями своих программ?
Ну молодец, че.
Reply
Какая разница? Мы пишем онлайновый видеоредактор не для Сергея Михалкова.
> В смысле - ты сам, лично, без ансамбля, пользуешься онлайн-версиями своих программ?
Я пользуюсь онлайновыми версиями чужих программ.
Reply
Leave a comment