[firefox-капец] Рендеринг через DX10

Нет, чтобы на openVG сделать

ну и ладно. если будет совсем не в моготу свалю на arora или midori.

А что собственно им мешает в лине прорисовку сделать через OpenGL?!

Просто при компиляции в зависимости от платформы будут активироваться различные фичи.

Может и сделают, но как-то сомнительно, что для unix-версии будут делать такое.

С какого они перепугу стали забивать? Они усердно стараются поддерживать все платформы с их возможностями. Будет и direct2d, и opengl будет. Не могут мозилловцы позволить себе такой роскоши, как кинуть макофилов и линуксоидов с бздуноидами.

>А что собственно им мешает в лине прорисовку сделать через OpenGL?!

Необходимо будет потратить время на написание прорисовки через OpenGL. Судя по тому, что мозилловцы не стали делать заранее прорисовку через OpenGL (это веб-страницы, всё же, а не Crysis), то скорее всего opengl вариации вообще не будет

Не совсем понятно на чём основаны сомнения? На кофейной гуще?

Т.е. есть технологии, позволяющие переложить часть работы по отображению графики с процессора на видюху, работающие и в Linux, и в оффтопе, и в латентно-гомо-оффтопе, и вообще везде? Я к тому, что Win7 - продолжатель (и по моему очень успешный) дела XP, за этой системой процентов 30 пользователей, как минимум (число с полки взял), и в ней эта технология УЖЕ ЕСТЬ и УЖЕ РАБОТАЕТ. А кто не спрятался - так это проблемы тех, кто не спрятался. Будет люди, которые проявят желание сделать что-то такое для «поделки прыщавых гиков» - хорошо. Нет - хорошо. Разница в рендеринге в 5 мс на гугле терпима.

Нет, просто фаерфокс для мака/линукса останется таким же тормозом, а фаерфос для винды станет ещё быстрее

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

Блин, вы голосу то включайте. А то это также смешно как если бы вы сказали, что мозилловцы пилят jit у tracemonkey под x86, но его вариации с arm вообще скорее всего не будет.
Это смешно, хотя бы потому что у них платформа компонентная, ничего не мешает сделать несколько бекэндов для рендера, абсолютно ничего.

Если так оно и будет, свалю в ближайшее время на webkit (Chromium, Arora, Midori).

Это просто маловероятный сценарий, учитывая конкуренцию. Для мозиллы подобный путь - путь в могилу. Они это прекрасно понимают. Тем более поддержка мака и линукса тут выражается в поддержке opengl/openvg - а не двух новых платформ. Кроме того есть ещё fennec, который работает зачастую там, где никакого direct нету, есть только opengl es. Вы же рисуете сценарий, при котором мозилловцы добровольно сдадутся на съедение, это как минимум наивно.

> Не могут мозилловцы позволить себе такой роскоши, как кинуть макофилов и линуксоидов с бздуноидами.

Уже не раз позволяли :)

Лучше бы по разным процессам вкладки разносили, получат отзывчивость как у хрома и глядишь будет счастье.

>Это смешно, хотя бы потому что у них платформа компонентная, ничего не мешает сделать несколько бекэндов для рендера, абсолютно ничего.

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

>Вы же рисуете сценарий, при котором мозилловцы добровольно сдадутся на съедение, это как минимум наивно.

Сценарий уже давно сыгран

http://digg.com/linux_unix/Firefox_Faster_In_Wine_Than_Native

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

Это ж вам не пропиетарщина какая-нить, а OSS проект, где все зависит от массы.

Драма-то какая. Мсявки недавно пропеарились, что IE 9 (или какой там на очереди?) будет рендерить страницы с помощью DirectX. Вот и мозилла пеарится. Как там на самом деле будет использоваться DX (и будет ли вообще) пока не ясно.

этож получается что мозиловцы собираются нарушить ГПЛ

поправьте если не прав

Как они могут нарушить что-то, что не используют? Да ещё так, как нельзя её нарушить?:D

>Сценарий уже давно сыгран

http://digg.com/linux_unix/Firefox_Faster_In_Wine_Than_Native

А это потому, что GTK - тормоз.

> А это потому, что GTK - тормоз.

Chromium.

spunky> Т.е. есть технологии, позволяющие переложить часть работы по отображению графики с процессора на видюху, работающие и в Linux, и в оффтопе, и в латентно-гомо-оффтопе, и вообще везде?

Да.

>> А это потому, что GTK - тормоз.

Chromium.

200.

>тормоз
Тормоз это ты, так как в FF и не пахло GTK, он только под него подстраивается.

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

> А это потому, что GTK - тормоз.
Линуксовая опера тоже медленнее, а она на QT.

>Да.

Можно поподробнее, что это за технология?

А ты посмотри на проблемы gnome-globalmenu, там даже менюбар ненативный, поэтом он не работает с ним. Мало того, он и в винде не нативный, если сравнить его с остальными, XUL просто тему копирует, как это делает qtgtkengine.

Пофиг, пересяду на iceweasel, который к тому времени станет самостоятельным форком.

То есть ты хочешь сказать, что ФФ написан не на GTK+ ?

>То есть ты хочешь сказать, что ФФ написан не на GTK+ ?
Прикинь, да. Он на XUL вообще то написан.

Тю, так вот почему оно такое тормозное гвно

> XUL просто тему копирует, как это делает qtgtkengine.

Это правда? В Ubuntu xulrunner зависит от libglib и libgtk2.0, зачем они там?

Если у них прорисовка на маке такая кривая, что не юзает аппаратное ускорение - то это их проблема сафари же легко и нипринужденно все на GPU сбрасывает и не боится

а подхватывать темы он должен из астрала?

>а подхватывать темы он должен из астрала?
Надо, кстати, предложить им libastral заюзать, может и под Qt станет нормально выглядеть

Так xulrunner использует Gtk+ или нет? Или просто мимикрирует под некий заданный виджетсет? Если можно, ссылочку, где о этом почитать. Я вот нашел неподтвержденные данные, что Gecko использует системный libgtk в качестве бэкенда для UI на XUL, т.е. виджеты-то в конечном итоге получаются Gtk-шные: http://forum.mozilla-russia.org/viewtopic.php?pid=176611#p176611 . И зависимость xulrunner'а от gtk это тоже подтверждает.

А это потому, что GTK - тормоз.

Не это потому, что XUL Runner тормоз и говно страшное. GTK на самом деле оч шустрый

>Это просто маловероятный сценарий, учитывая конкуренцию. Для мозиллы подобный путь - путь в могилу. Они это прекрасно понимают. Тем более поддержка мака и линукса тут выражается в поддержке opengl/openvg - а не двух новых платформ. Кроме того есть ещё fennec, который работает зачастую там, где никакого direct нету, есть только opengl es. Вы же рисуете сценарий, при котором мозилловцы добровольно сдадутся на съедение, это как минимум наивно.

Какой ужас, Мозила конечно же сразу загнеться потеряв 0.5% десктопов на которых используется Линукс версия ФФ.

>Chromium.
А что, он не тормознее хрома под венду?

>Тормоз это ты, так как в FF и не пахло GTK, он только под него подстраивается.
Да ну, правда? И как же это он так делает то, а?

>Линуксовая опера тоже медленнее, а она на QT.
В опере от QT только менюшка.

Сначала надо научиться внимательно читать, а уже потом писать. mac+linux+freebsd+fennec(simbian,n800-n900) - уже сейчас далеко не 0,5 процентов. В перспективе будет не мало. Так вот на всех этих платформах никакого directа нету, и для мозиллы поддержка ускорения на всех платформах сразу упирается в поддержку семейства opengl, opengl es, openvg. Что не так уж сложно сделать.

А что, он не тормознее хрома под венду?

Аналитики говорили, что он быстрее

>> Chromium.

А что, он не тормознее хрома под венду?

http://www.linux.org.ru/view-message.jsp?msgid=4195476

My three laptops have relatively comparable hardware and run Chrome on Windows, Mac, and Linux respectively. The Linux version of Chrome feels ridiculously faster than Windows and Mac. Do we understand why this is? Can we make Windows and Mac feel that fast too?

General observations:

1) Scroll performance is extremely good. Even on Gmail, I can only get the mouse to lead the scroll bar by a dozen pixels. On Slashdot, it doesn't even look like I can do that.

2) Tab creation is very fast. Maybe the zygote is helping here? Can we pre-render the NTP on other platforms?

3) Startup time is faster than calculator.

Adam

On X-windows, the renderer backingstores are managed by the X server, and the transport DIBs are also managed by the X server. So, we avoid a lot of memcpy costs incurred on Windows due to keeping the backingstores in main memory there. I suspect this is at least one of the bigger issues.

I also suspect that process creation is a problem on Windows. We should probably look into having a spare child process on Windows to minimize new tab jank. Maybe there is a bug on this already?

>>А это потому, что GTK - тормоз.

Не это потому, что XUL Runner тормоз и говно страшное. GTK на самом деле оч шустрый

Нечего приписывать мне не мои слова. Будьте внимательнее при цитировании.

>mac+linux+freebsd+fennec(simbian,n800-n900) - уже сейчас далеко не 0,5 процентов

Ну 10 процентов. Не потеряют конечно, пипл тормоза схавает :)