Часто народ недоумевает, почему в такой быстрой OS такой медленный браузер?

На то есть разные причины, но ситуация меняется к лучшему.
И свидетельство тому — последняя сборка StripZilla for BONE на bebits.com

http://www.bebits.com/app/2715
http://www.bebits.com/bob/14174/mozilla-i586-pc-beos-Jetgfx–1.3.b1.tar.gz
(адрес архива может меняться, так что лучше сходить на страницу, если будут проблемы с загрузкой)

Кроме субъективных причин — после того, как основной костяк Mozilla для BeOS был сделан, она осталась практически без разработчиков (1,5 человека — это не команда), есть и объективные причины, связанные, в основном, с переносом программы из, по сути, однопоточной OS (Windows) в многопоточную (BeOS).

И если, в теории, многопоточность предоставляет значительные преимущества в создании «отзывчивых» программ, то при портировании чужой «однопоточной» программы обычно делается все, чтобы многопоточность «изничтожить».

Но это теория, а реальных проблем в нашем случае две.

1) Mozilla для Windows и Mozilla для Linux рисуют прямо в графическое железо, там, где это возможно — однопоточная система может себе это позволить. В BeOS это затруднительно, хотя, в прниципе, можно использовать класс BDirectWindow. Но это потребовало бы капитальной перестройки всего порта — так что пока не актуально.

2) Особенность многопоточных систем — необходимость блокирования (Lock) при любой акции, связанной с взаимодействием с ApplicationServer — например, при рисовании картин или текста. Соответственно, после отработки акции, необходимо разблокировать (Unlock) окно (или другой «приемник сообщений»). А это процесс весьма затратный, особенно деблокировка, и зачастую занимает в разы больше времени, чем сама акция.

Но тут есть выход. Так как Mozilla производит все рисование с использованием двойной буферизации — то есть сначала весь вид/страница отрисовываются не на экране, а на специальной «поверхности» — а потом поверхность разом копируется в окно — можно попытаться блокировать поверхность один раз, при ее создании, и деблокировать при разрушении. При таком подходе окно реально будет блокироваться один раз — только при переносе на него изображения со вспомогательной поверхности.

Что и было сделано в последней сборке.

Кроме того, исправлено обрамление форм и кнопок (было слишком толстое) — в результате чего должна исчезнуть проблема с невидимым курсором в начале однострочных полей ввода.
Также была ускорена обработка анимированных картинок и вывод текста.

Есть, правда, и третья проблема, тоже связанная с многопоточностью, точнее, с ее «изничтожением». В нормальных BeOS–приложениях, части программы передают друг другу и операционке сообщения независимо и параллельно при необходимости — в Mozilla для BeOS по необходимости все направляется в одно «бутылочное горлышко» (message proxy), откуда дальше распределяется через собственные механизмы Gecko/Necko/NSPR.

Проблема не очень критическая, но здесь можно было бы улучшить ощущение «отзывчивости» на действия пользователя.

Так или иначе, по отчетам тестеров, новая сборка уже может работать относительно терпимо на машинах класса Pentium 150–200. Единственно, что при наличии памяти меньше 96–128 MB результаты будут малоудовлетворительны.

P. S. Для слабых машин я крайне рекомендую убрать лишние кнопки с интерфейса, запретить лишние панели и всплывающие подсказки, и, самое главное — убрать анимацию (например, сделать ее однопрогонной).

NB!!! Эта сборка требует чистой инсталляции, то есть в пустую папку. При инсталляции поверх старой версии могут быть проблемы