> ilnurathome (*) (18.11.2007 22:54:44)
Ему реально нужен расширенный метод управления вкладками, сортировка, группировка и т.д.

>вкладок скопилось.... щас посчитаю.... 109 открытых вкладок.

http://bash.org.ru/quote/244083

//captcha: living

>реально нужен расширенный метод управления вкладками, сортировка, группировка и т.д

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

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

>стоит забыть очистить список загрузок начинает тормозить, очистишь снова разгоняется, что там не то.

ну учитывая что оно наверно хранится в RDFDatasource, который соответствует какому-то *.rdf в профиле, то получаем алгоритм Шлемиля при обновлении такого RDF.

У меня тоже за 3 года ScrapBook разросся на 4.5 Gb, и при просмотре списка ощутимо тормозит. Когда столкнулся с тем, что Фокс терял вкладки с прошлой сессии, стал принудительно сохранять сессии руками (в папку в букмарках, добавить все вкладки с именем YYYY-MM-dd). То же тормозаа при разрастании bookmarks.html свыше определенного размера.

В Опере оно похоже хранится в какой-то хеш-структуре и таких тормозов нет.

о-о-о, не надо тро таскбар. почему за столько лет ни один (НИ ОДИН!) гений не реализовал простую вещь — drag'n'drop кнопок задач? чтобы я мог поменять их местами? пустышки.

> о-о-о, не надо тро таскбар. почему за столько лет ни один (НИ ОДИН!) гений не реализовал простую вещь — drag'n'drop кнопок задач? чтобы я мог поменять их местами? пустышки.

Под гномом их можно перетащить и поменять местами

>anonymous (*) (18.11.2007 22:48:36)

>ну в Safari тоже поломанный onLoad()

поломаный вызов события onload — это не так страшно, как сломаный язык. в DMDScript тупо не работает совершенно легальный код. точнее, работает, но неправильно. а я, например, closures использую весьма активно.

>anonymous (*) (18.11.2007 22:55:16)

>То есть тормоза JS — критические для pipeline.

не совсем понял. понятно, что если JS тормоз, то тормозить загрузка ещё как будет. я говорил о том, что сама работа с DOM из JS — тот ещё источник горячей финской скорости. пофигу, насколько оптимизирован остальной JS-код, если простые манипуляции с DOM дико тормозят.

а они не могут не тормозить, потому что reflow. не знаю, как в фоксе — в Опере это пытаются решить запуском reflow после отработки скрипта (или если скрипт работает дольше определённого времени). в идеале reflow вообще должен работать где-то там на фоне, и ожидание должно быть только если JS пытается узнать координаты передвинутого объекта.

плюс — за счёт усложнения логики можно попытаться изолировать регионы, которые «поползут» и вообще не делать reflow, пока видимыми не станут.

возможно, это баян, и давно так сделано — не знаю. я не настолько крут, чтобы исходники гекона читать. %-)

однако судя по наблюдениям — reflow делается для всего документа, а не только для потенциально видимых регионов.

>Под гномом их можно перетащить и поменять местами

искренне и беззлобно завидую гномовцам.

>cама работа с DOM из JS — тот ещё источник горячей финской скорости

вообще да. По идее, мы должны иметь какие-то куски-сниппеты, которые могут работать с DOM параллельно, одновременно. Они не обязаны работать под интертрепатором, скорее надо хоть раз откомпилировать в JIT.

>в идеале reflow вообще должен работать где-то там на фоне, и ожидание должно быть только если JS пытается узнать координаты передвинутого объекта.

типа выделить куски JS который инвариантен к DOM.

>плюс — за счёт усложнения логики можно попытаться изолировать регионы, которые «поползут» и вообще не делать reflow, пока видимыми не станут.

вот была бы эта дура reflow на lisp с ленивыми вычислениями, и сиё получилось бы автоматом. Преобразовать XML/HTML в Sexprы, которые сами себя рисуют. Вызывать эти Sexprы лениво только когда нужен reflow, и только ту часть, что попадает в окошко-viewport. Кешировать все и вся, и обеспечить персистентность прозрачной фоновой ниткой, которая будет этот кеш сбрасывать. Скрипты, которые преобразут DOM запускать лениво, в closure'ах, в уже откомпилированном скешированном виде.

вроде есть какой-то бровзер Closure на Common Lisp, хз как у него со стандартами.

>однако судя по наблюдениям — reflow делается для всего документа, а не только для потенциально видимых регионов.

по логике, мы можем не знать ширину столбца в таблице, пока не узнаем ширину всех (неподгрузившихся) клеток столбца с непрописанными тегами width

>возможно, это баян, и давно так сделано — не знаю. я не настолько крут, чтобы исходники гекона читать. %-)

хз, тоже кто бы грамотно просветил про потроха ящура. Вроде есть платформа с XPCOM, есть персистентность с RDF датасорсами, есть метаданные в RDF, что-то описывающие. Есть gecko и куча лапши на JS, которая дергает за интерфейсы gecko и XPCOM. кто бы просветил дальше, как и зачем оно это делает?

>По идее, мы должны иметь какие-то куски-сниппеты, которые могут работать с DOM параллельно, одновременно.

да хотя бы возможность пустить новым потоком кусок, который точно ни к чему особо не обращается. типа t = spawnThread(func);/waitForThreadCompletion(t);/lockDOMTree()/unlockDOMTree();

для, например, какой-то там обработки страницы, не меняющей контент. или — закэшировать нужные куски, пнуть поток, поток отработал — лочит дерево, насилует и тогда уже reflow. а то щаз пока js работает — брофзер спит…

>вот была бы эта дура reflow на lisp с ленивыми вычислениями, и сиё получилось бы автоматом. Преобразовать XML/HTML в Sexprы, которые сами себя рисуют. Вызывать эти Sexprы лениво только когда нужен reflow, и только ту часть, что попадает в окошко-viewport.

авотфиг. я тут подумал… очень часто даже чтобы понять, что в экран попадает, всё равно надо reflow делать. %-(

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

>по логике, мы можем не знать ширину столбца в таблице, пока не узнаем ширину всех (неподгрузившихся) клеток столбца с непрописанными тегами width

да и фиг с ним. progressive и так рендерит бредятину с таблицами.

вообще, тут таки есть над чем раскинуть моском. но это надо брать литру и закусь хороший… %-)

>кто бы просветил дальше, как и зачем оно это делает?

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

?>A<>B@5;-B0:8 hv3. ?@>1CN 87-?>4 =53> =0?8A0BL.

4>;65= ?@87=0BL, GB> 2?>;=5 8=B5@5A=>. @5=45@8B. 4065 >G5=L ?@024>?>4>1=>.

?>445@6:C dhtml =5 A<>B@5; ?>:0.

A:>@>ABL ?@8OB=> ?>@0605B: ?>GB8 :0: ?5@0. %-)

hv3

мда. факир был обкурен, и всё выступление проржал.

выше — это hv3 был. рисовать оно рисует (правда, только utf8 и koi8, видимо, koi8 из-за локали). даже вполне правдоподобно рисует. даже suckerfish работает.

и скорость приятная — почти как Опера.

однако, на моём e107 его скособочило так, что смотреть невозможно. но это мелочи.

в общем — ребята молодцы. глядишь — и допилят скоро до чего-то, на чём можно будет построить альтернативу лисе и уесть Оперу по скорости. %-)

>мда. факир был обкурен, и всё выступление проржал.

из того, что нашел по-быстрому: не работают кодировки, выбор шрифтов, установить кодировку через <meta http-equiv="Content-Type" content="text/html; charset=windows-1251">, фреймы не всегда правильно отрисовываются, а так ничего, "перспективный пациент"(c)доктор :-)

>не работают кодировки

да и фиг бы с ними. давно пора всё перевести на UTF-8 (как я её ненавижу! %-).

>выбор шрифтов там на сайте написано, что оно знает только два типа шрифтов, и те hardcoded. но это как раз ерунда (как и кодировки), главное — layout и rendering. %-)

>фреймы не всегда правильно отрисовываются

да вы, сударь, Великий Маг. у меня это «не всегда правильно» выглядит как «всегда неправильно». %-)

впрочем, в стиле ЛОРа: фреймы не нужны.