понедельник, 29 октября 2012 г.

Проект народного финансирования веб-браузера

UPD 23.05.2013: Я приношу свои извинения всем тем, кто решил поддержать меня. Так как фактически я не выполнил своих обещаний, в ближайшее время я начну возврат средств всем тем, кто их мне пожертвовал. Это не означает, что разработка браузера будет остановлена; я не прекращал работы над ним, и не собираюсь прекращать. Если вы один из тех, кто не хочет, чтобы я возвращал ваши средства (такие люди есть), пожалуйста, напишите мне письмо. SoUrcerer

32 комментария:

  1. Может здесь стоит оставить ссылку на Хабрахабр?

    ОтветитьУдалить
  2. Этот комментарий был удален автором.

    ОтветитьУдалить
  3. Ну - приступайте!) Вам удачи..

    ОтветитьУдалить
  4. Ответы
    1. У меня нет аккаунта на хабре, но mithgol прав-основная сумма не с хабра!;-)

      Удалить
  5. Успехов Вам, искренне желаю, чтобы всё получилось.
    Если через месяц результат будет, дальше получать достаточное финансирование будет проще.

    ОтветитьУдалить
  6. Я верю в этот проект по одной простой причине - Refactoring больших проектов нецелесообразен, поэтому иногда получаются колоссы на глининых ногах. В то же время, требования к современному браузеру проясняются: HTML5+CSS+JS. И желательно не создавать несовместимостей))

    ОтветитьУдалить
  7. Посмотрел вашу KolibriOS. В таком духе как там все написано -- сделаете, конечно...

    Но выглядит все, мягко говоря, как студенческая поделка... Тот же калькулятор -- доп. нули выводит зачем-то, при двойном нажатии на "=" -- какие-то неадекватные действия происходят.

    Зачем все это? Какова конечная цель?

    ОтветитьУдалить
    Ответы
    1. Уважаемый анонимный комментатор. Калькулятором много лет никто не занимался, его разработка прекратилась за несколько лет до моего прихода в проект. Имейте это в виду.
      Размышлять о философских вопросах я сейчас, увы, настроения не имею. Вопросы "зачем" и "ради чего" задавались многократно, и ответы на них давались так же многократно. Система находит своё применение, и прикладное ПО для неё - тоже. Спасибо за внимание.

      Удалить
  8. Такое ощущение, что автор не представляет сложности задачи. Это, конечно, не Денис Попов. Но замашки похожие.
    Растеризатор векторного шрифта интересен, а вот предложение использовать его в Embedded девайсах и ZX Spectrum - смешно :) Там тупо памяти и вычислительной мощи не хватит.
    Какой-то юношеский максимализм новоиспечённого "молодого специалиста"...

    ОтветитьУдалить
    Ответы
    1. >предложение использовать его в Embedded девайсах и ZX Spectrum - смешно
      Да ладно? На микроконтроллерах такой алгоритм вполне работоспособен. Особенно хорошо работает, если растеризацию делать один раз, при загрузке шрифта. Не вижу причин, способных помешать использованию данного алгоритма на Spectrum.

      Удалить
    2. В том числе из-за того, что вы не видите этих причин, и возникают сомнения в адекватности оценки вами сложности задачи.

      Цитата: "Размер скомпилированной программы — 2589 байт, максимальное использование ОЗУ — около 300 килобайт. И это не предел! "

      Ресурсы обычного ZX Spectrum: до 20 MHz, менее 48 KiB и на код, и на данные, т.к. вся программа хранится в RAM.
      Не самые слабые микроконтроллеры типа STM32F1: до ~72 MHz, 64-96 KiB RAM, 256-512 KiB ROM.

      1. Куча операций умножения/деления;
      2. Хранить шрифты в текстовом формате SVG и парсить их при каждом выводе?
      3. 300 килобайт ОЗУ для вашего алгоритма? Серьёзно?
      4. Антиалиасинг для монохромного экрана? Вы шутите, да??)
      В ZX Spectrum всего один бит на точку, цвета точек и фона определяются сразу для группы 8x8 точек.
      Во встраиваемых системах монохромные дисплеи всё ещё сильно распространены, у них небольшие требования к ресурсам контроллера и простой алгоритм управления.

      У меня, например, растровый шрифт высотой 14 точек для латинских (коды 32-127) и русских (от А до я) символов занимает 8588 байт. Вывод практически мгновенный. Зачем все эти навороты, которые ничего не дают, кроме траты вычислительных ресурсов и памяти?

      Всё ещё не видите причин?

      Удалить
    3. Я не говорил про STM32, лишь про ATMega. Для шрифта экранного размера операций деления не более двух десятков на глиф, и то - при загрузке шрифта. Кстати, шрифт отлично конвертируется в двоичный формат, и занимает около 8 килобайт для русских и английских символов, а так же цифры и знаков препинания. 300 килобайт ОЗУ необходимо для шрифтов, пригодных к печати. Алгоритм не требует антиалиасинга, это опция.

      А теперь - контрольный. Посмотрите на ветку Колибри-А, в ней используются векторные шрифты, и они работают быстрее, чем растровые (8x5), и занимают меньше места в памяти.

      Удалить
    4. К слову, STM32 более мощные контроллеры, чем ATMega.

      Т.е. при загрузке переводим SVG в растр и храним в ОЗУ. Почему бы сразу не хранить растр в ПЗУ?
      Пусть даже 8 килобайт. Вы считаете, что в микроконтроллерах настолько много лишней оперативной памяти, что можно тратить её на хранение ресурсов, преобразованных из источника в ПЗУ?
      И ещё там, как бы, нет встроенных библиотек парсинга XML документов.

      Контрольный - а вы уверены, что метод вывода растровых шрифтов у вас оптимизирован?

      Удалить
    5. Разумеется, STM32 - более мощные. Мне, увы, не доводилось работать с ними столько, сколько с Мегой.

      SVG конвертируется в двоичный формат векторных шрифтов до прошивки в память, а не после. Для многих задач вполне достаточно использования растровых шрифтов, но не всегда можно обойтись только ими. Начиная от банального желания вывести крупную надпись на графическом экране :)

      Оптимизирован, и работает быстрее, чем отрисовка растровых шрифтов средствами GDI в Windows.

      Удалить
    6. В итоге получается, что область применения начинается с микроконтроллерных устройств с внешним ОЗУ и цветными дисплеями. И контроллер мощный, и шрифт после растеризации есть где хранить, и экран большой.
      Если так, то убедили.

      Удалить
    7. Именно, как-то так. Если у контроллера дисплей символьный - то вряд ли для него понадобятся векторные шрифты. Все равно программировать на большинстве таких дисплеев можно только несколько символов.

      Удалить
  9. Господа! Сам по себе браузер для колибри которая спокойно идёт даже на pentium1 и выше это вообще фантастика и прорыв! Браузер станет локомотивом всей ОС и после браузера Колибри уже не будет маргинальным, игрушечным проектом. Сама идея интернета для старых ПК, которых десятки миллионов стоят на чердаках и выкидываются. После браузера это железо снова заработает. Причём с пользой. А из этого можно и выгоду извлечь не в ущерб в интерес пользователям!

    ОтветитьУдалить
  10. Что новенького? Как продвигается разработка?

    ОтветитьУдалить
  11. Прошло более 4-х месяцев, но никто так и не увидел результат.
    Я следил за новостями (точнее за их отсутствием) с самого начала. С каждым днем мои надежды угасали.
    Жаль что Вы не оправдали наших ожиданий.

    ОтветитьУдалить
    Ответы
    1. Вы всё-таки чего-то реального ожидали?)
      Веб-стандарты пишут годами и крупными коллективами, браузеры тоже. Заявленная задача недоступна одному человеку в реальные сроки, очевидно.

      Удалить
    2. Прошу прощения, но всё же заявленная задача доступна одному человеку в реальные сроки.
      Однако для того, чтобы "догнать паровоз", нужно несколько больше времени, чем я изначально рассчитывал, к сожалению. Кроме HTML, CSS, JS и DOM (которые уже реализованы или портированы в минимально достаточном для современного веба объеме), требуется немалое количество дополнительных технологий. Учитывая их количество и среднюю скорость разработки, я пришел к выводу, что всё, что мне остается сделать - извиниться перед всеми, вернуть собранные деньги, и продолжить разработку. Впереди еще не меньше полугода работы.

      Удалить
    3. Недоступна. Вы переоцениваете человеческие возможности, и свои в частности.
      За то время, что вы будете это дописывать, выйдет кучка новых стандартов и ещё +10 версий хрома с лисой.

      Удалить
    4. Хотите сделать - соберите группу разработчиков.

      Удалить
  12. Этот комментарий был удален администратором блога.

    ОтветитьУдалить