Что в них берется за основу отрисовки окна? Если, к примеру, это был бы битмап, а информация просто бы подгружалась из памяти в зависимости от положения скрола, то это дело бы дело жутко тормозило. Ну я вас умоляю только без подколов ) Я, как начинающий, еще во многих вопросах плаваю

> Что в них берется за основу отрисовки окна?


Положение скроллбара

> Что в них берется за основу отрисовки окна?

Не поверите, окно windows :)


> а информация просто бы подгружалась из памяти в зависимости
> от положения скрола

Так и есть, только не из битмапа, конечно, а из RenderTree


> то это дело бы дело жутко тормозило

К счастью, сейчас уже не 1997-й год, но рендеринг всё ещё остаётся ресурсоёмкой операцией
мой процессор в "спокойном" состоянии занят на 1% при частоте 1.6 ГГц
если поскроллить вверх-вниз страницу дельфимастера в хроме, то загрузка становится 6% при частоте 2.4 ГГц

более подробно есть в этих ваших интернетах:
https://github.com/adobe/webkit/tree/master/Source/WebCore/rendering

Экран у вас 2000х1000×4 байта. Скорость ОЗУ 20 ГБайт/с.
Сколько кадров в секунду может выдать ваша ЭВМ?  А коково время реакции вашего мозга?


> Так и есть, только не из битмапа, конечно, а из RenderTree

Нюю. Как раз таки вывод идёт из битмапа, а рендеринг идёт в битмап. Так как рендеринг медленее раз в 100 чем просто скопировать картинку. Rendering, если переводить дословно, - это построение изоброжения.
А за основу и правда берётся RenderTree, что бы съэкономить на памяти.
Вот в браузере дела обстаят иначе из-за анимации картинка постоянно меняется и там её нет смысла её хранить, отрендерили объекты и тут же вывели.

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

у меня, можно сказать, битмап. отрисовывается и скроллируется 4750 записей (больше нет в бд), каждая высотой около 16 пикселов, шириной во весь экран. не тормозит.
потому что на самом деле, отрисовывается только то, что вмещается в окно, плюс одна строка выше окна и одна строка ниже окна (чтобы создавался эффект убегания строк за границы).
На самом деле, основная сложность - подсчет размеров скроллбара при неоднородном содержимом.

мне вот интересно, как реализован механизм выделения текста.

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


> если поскроллить вверх-вниз страницу дельфимастера в хроме,
>  то загрузка становится 6% при частоте 2.4 ГГц


Взял paintbox и scrollbar, в stringgrid загрузил кусок текста, по скролу сделал вывод в paintbox текста через textout. - при быстром скроле загрузка 60-90%, хоть с промежуточным битмапом хоть без него

> Я, как начинающий, еще во многих вопросах плаваю


Скачать исходники браузера и поискать там ответы на вопросы не предлагать ?

> Скачать исходники браузера и поискать там ответы на вопросы
> не предлагать ?

А у вас есть браузер который целиком написан на Delphi?

>  браузер который целиком написан на Delphi?

если бы он был написан на Аде (или подобном сильно отличающимся языке), еще можно было бы сказать, что не катит. В остальных случаях нет разницы, ибо речь идет об алгоритме.

А с выделением у вас какие проблемы?

Процесс выделения довольно хорошо описан в книге:
(Библиотека программиста) Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес-Приемы объектно-ориентированного проектирования. Паттерны проектирования-ДМК Пресс (2010)

> Pavia ©   (06.03.17 20:02) [10]

тотальные :) как выделить нарисованный текст? для частного простого случая проблемы нет, например, если все символы одинакового размера и расстояние между ними тоже фиксировано. Но если текст разный, если выведен GDI+, то единственный вариант, который мне видится, связан с офигенным пересчетом размеров-координат каждого символа.

> Pavia ©   (06.03.17 20:05) [11]

спасибо, не попадалось. прочитаю.

> то единственный вариант, который мне видится, связан с офигенным
> пересчетом размеров-координат каждого символа.

На то он и процессор что-бы считать. Да перебором. Средняя книга 1 мб.
Процессор всю её переберёт за 0٫01-0٫1 секунд. В браузерах из-за обёрток этот процесс несколько медленнее 1-10 секунд.
Но им обычно за скоростью гнаться и не надо, так как работают с документами в 10-100 раз меньше.

Весь документ бьётся на горизонтальные ряды ячейки или на вертикальные строки. Те в свою очередь тоже бьются на ряды и строки. Так получается сложное пространственное дерево. Для обхода применяются бегунки(интераторы) которые умеют обходить скрытые структуры от первого и до последнего элемента.
Абстрактный бегунок обладает рядом умений, заложенных в него алгоритмов. К примеру не просто прямой перебор, а дихатомией. Тогда можно ускорить выделение не перебирая все элементы массива, а сразу отсекая лишние строки или столбцы.

Соответственно при выделение вначале ищется крайние элементы, а потом уже обходится всё дерево.

> aka ©   (06.03.17 18:42) [6]
> Довольно интерный вопрос, как лично мне кажется, сходу и
> не нашел толковых статей реализации сего дела.> если поскроллить
> вверх-вниз страницу дельфимастера в хроме,>  то загрузка
> становится 6% при частоте 2.4 ГГцВзял paintbox и scrollbar,
>  в stringgrid загрузил кусок текста, по скролу сделал вывод
> в paintbox текста через textout. - при быстром скроле загрузка
> 60-90%, хоть с промежуточным битмапом хоть без него


Я сделал такой тест. 700 Мгц загрузка одного ядра поднимается с 10 до 30%

procedure TForm1.ListBox1DrawItem(Control: TWinControl; Index: Integer;
 Rect: TRect; State: TOwnerDrawState);
begin
ListBox1.Canvas.TextOut(Rect.Left, Rect.Top,ListBox1.Items[Index]);
end;

procedure TForm1.FormCreate(Sender: TObject);
var i,j:Integer;
s:String;
begin
ListBox1.Style:=lbOwnerDrawFixed;
for i:=0 to 1000 do
begin
 s:='';
 for j:=0 to 200 do
  s:=s+char(random(64)+Ord('A'));
 ListBox1.Items.Add(IntToStr(i)+':'+s);
end;
end;

Мерить загрузку диспетчером задач не хорошо. Так как он реагирует только на очередь сообщений. Поэтому это нормально что ваш код показатель 90%
А TListBox использует очередь сообщений и каждая отрисованная строчка эта  заход и выход из очереди сообщений. ОС имеет возможность с планировать нагрузку и сделать паузу между их отрисовками.
И основы отрисовки и оптимизации можно почерпнуть из исходников того же TListBox он не рендерит все строчки, а только те что отображаются в данный момент на экране.

Забыл вставить, что-бы белое снизу не моячило надо включить двойную буферизацию.


> ListBox1.DoubleBuffered:=True;

> Pavia ©   (06.03.17 20:29) [14]

я вообще надеялся вначале, что есть какой-то винапишный функционал. а нет...

> А у вас есть браузер который целиком написан на Delphi?

Есть и такие. Кривоватые и ограниченные, но ответ на вопрос данной ветки там найти можно.

Pavia ©   (06.03.17 21:14) [15]


> Я сделал такой тест.


Вот это истинное лицо delphimaster.ru, бессмысленное и беспощадное.

> Pavia ©   (06.03.17 21:14) [15]
> Я сделал такой тест. 700 Мгц загрузка одного ядра поднимается
> с 10 до 30%


А размер окна какой? Размер окна сильно влияет на результат

> Есть и такие. Кривоватые и ограниченные, но ответ на вопрос
> данной ветки там найти можно.

Не крутовато будет? А просто описать основополагающие принципы темы вопроса никто наверное не может?

Размер на весь экран1280х1024 минус панель пуск.
А какие Вам принципы нужны?

> минус панель пуск.

не всегда. в одном случае из трех.

Наверное мне нужно немного переформулировать вопрос. Все в общем нормально работает, а все эти тормоза из-за DOUBLEBUFFERED, но без него мерцает (
а проц почти не грузится. Можно избавиться от мерцания подешевле чем через DOUBLEBUFFERED?

> Все в общем нормально работает, а все эти тормоза из-за
> DOUBLEBUFFERED, но без него мерцает (а проц почти не грузится.
>  Можно избавиться от мерцания подешевле чем через DOUBLEBUFFERED?

А версия Delphi у вас какая?

D7  используется псевдо двойная буферизация - она не тормозит. В XE используется двойная буферизация, можно сменить её тип на совместимой с D7 делается одной строчкой.

Можно написать форму на WinAPI и "убрать" лишнее стирание фона. Не помню точно перехватывается оно или отменяется.

Либо уходить на OpenGL, DirectX, Vulkan они работают быстрее.  Особенно когда вычисления написаны так что-бы они велись на GPU и GRAM. GRAM - по быстрее будет да и GPU, производительнее чем CPU.
Использование OpenGL, DirectX, Vulkan - не означает автоматом, что все расчёты у вас будут на GPU, нужно правильно писать код.

> Pavia ©   (07.03.17 12:33) [26]


> нужно правильно писать код.

Это сложный вопрос )))

> А версия Delphi у вас какая?

D7

Тогда берёшь SamplingProfiler-1.8.1 смотришь что тормозит и оптимизируешь те методы и функции. Добавляешь кэширование.

Я бы не советовал автору ветки с наскоку браться за это дело. Есть у меня в практике такой проект - полноценный HTML браузер поддерживающий рендеринг страниц обьемом в 60-80 мегабайт только верстки (даже хром с таким не справится, а у нас и до 200 метров доходит иногда) ну и плюс картинки - там объем бешеный.
Писалось это дело почти семь месяцев двумя не совсем глупыми программистами - умаялись, если не сказать больше, даже в какой-то момент вообще хотели кинуть эту беду, но смогли реализовать.
Если смотреть сейчас - я бы больше никогда за такую задачу не взялся

> Rouse_ ©   (07.03.17 22:00) [29]

Полноценный своими руками? С DynamicHTML, CSS (включая :hover) и JS?

> DayGaykin ©   (07.03.17 22:25) [30]
>
> > Rouse_ ©   (07.03.17 22:00) [29]
>
> Полноценный своими руками? С DynamicHTML, CSS (включая :
> hover) и JS?

Давай сейчас принародно признаемся кто нам с Женей для этого контрола масштабирование делал, да Дим? ;)
Я думаю я ответил на твой вопрос :)

> Rouse_ ©   (07.03.17 22:00) [29]


>  Есть у меня в практике такой проект - полноценный HTML
> браузер поддерживающий рендеринг страниц обьемом в 60-80
> мегабайт только верстки

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

Документация сметная, чтоб отобразить приходится на страницы разбивать. Некоторые документы размером в две с половиной тысячи страниц выходит, ну и по обьему соответственно не маленькие.
Вот так выглядит: http://www.grandsmeta.ru/images/st-7.jpg