CS>>У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти.
_>Безусловно его нет. Более того, если бы обмен данными между обычной памятью и видео-памятью происходил с помощью инструкций CPU, то это было бы катастрофически медленно. Однако в CPU (и не только — сейчас это уже даже в копеечных МК присутствует) имеется такой механизм работы с периферией как DMA, который позволяет периферийным устройствам обмениваться с памятью процессора в фоне (без его прямых команд). Соответственно при включение этого механизма запись в определённые разделы оперативной памяти по сути полностью аналогична записи в видео-память. И думаю что большинство участников дискуссии имели в виду именно это, просто не расшифровывая очевидные детали.
"Как DMA" — это называется bus mastering, который подвид DMA, позволяющий устройствам напрямую работать с памятью. Но речь не про него, а про memory-mapped space, которое фактически мапит IO порты на АП физической памяти и позволяет CPU инструкциям работы с памятью общаться с девайсом _без_ реального использования физической памяти. DMA тут вообще никаким боком не относится. Работает, разумеется, медленее чем доступ к локальной физической памяти, и работая с таким отображением надо отдавать себе в этом отчет. Кэширование там есть, но минимальное.
Замечу, что bus-mastering активно используется встройками которые не имеют своей видеопамяти и таким образом юзают системную память, в том числе и для фреймбуфера. Но речь, повторюсь, не про этот usecase.

CS>Т.е. для того чтобы пользовать AlphaBlend ты тот DIB должен заполнить как-то, т.е. исполнить rasterization всех примитивов в памяти т.е. с помощью CPU (GDI, GDI+, AGG, etc.). Никакой per primitive hardware acceleration как ты понимаешь в этом случае не будет — физически невозможно в современных архитектурах. Т.е. для high-dpi monitors GDI это смэрть ибо там рисование O(N).
CS>Единственное место для H/W acceleration это заброс той битмап из памяти в video memory. Т.е. фактически древний как дерьмо мамонта механизм DMA или подобного.
Аппаратно ускоряется:
1) заброс src битмапа из памяти в видеопамять
2) натягивание этого битмапа на dst битмап (который уже в видеопамяти)
Причем надо понимать что аппаратное ускорение — это не только "сделать все быстрее чем делает CPU", но еще и offload вычислений с CPU. Так что если по абсолютной скорости оно будет так же как чисто софтверный рендеринг, но освободит CPU для других задач — это тоже очень хорошо. И совершенно непонятно чем вам не нравится прекрасно работающий механизм, неважно когда он там был разработан.

Здравствуйте, ononim, Вы писали:

CS>>Т.е. для того чтобы пользовать AlphaBlend ты тот DIB должен заполнить как-то, т.е. исполнить rasterization всех примитивов в памяти т.е. с помощью CPU (GDI, GDI+, AGG, etc.). Никакой per primitive hardware acceleration как ты понимаешь в этом случае не будет — физически невозможно в современных архитектурах. Т.е. для high-dpi monitors GDI это смэрть ибо там рисование O(N).
CS>>Единственное место для H/W acceleration это заброс той битмап из памяти в video memory. Т.е. фактически древний как дерьмо мамонта механизм DMA или подобного.
O>Аппаратно ускоряется:
O>1) заброс src битмапа из памяти в видеопамять
O>2) натягивание этого битмапа на dst битмап (который уже в видеопамяти)
O>Причем надо понимать что аппаратное ускорение — это не только "сделать все быстрее чем делает CPU", но еще и offload вычислений с CPU. Так что если по абсолютной скорости оно будет так же как чисто софтверный рендеринг, но освободит CPU для других задач — это тоже очень хорошо. И совершенно непонятно чем вам не нравится прекрасно работающий механизм, неважно когда он там был разработан.

Ну наконец-то, прозрел. Т.е. ты только что сказал буквально следующе "DDB это память" и "только BitBlt и AplphaBlend аппаратно ускоряются".
(На самом деле полный список: BitBlts, AlphaBlend, TransparentBlt, and StretchBlt)

Все остальные GDI функции — чисто CPU rasterization.

Т.е. "offload вычислений с CPU" это не про GDI, этим занимаются DirectX, OpenGL, Vulcan, Metal и иже с ними.

Здравствуйте, Ikemefula, Вы писали:

I>Рефакторинг в твоём случае ограничен перформансом IDE. И рефакторинг вобщем глобальный инструмент. Локально можно побороть проблему десятком разных способов, хоть взять влоб да переписать.
А нельзя ли выражать свои мысли яснее?

I>вижла в 2003м была 32х битная, а это значит 2гб на процесс и кердык.
Не вижу связи. У меня до сих пор вижуалка 32битная

I>SSD массово начали ставить совсем недавно. в 2003м SSD даже у гиков не было.
Опять таки, это тут при чём?

Здравствуйте, Ikemefula, Вы писали:

I>Тогда понятно, почему рефакторинг у CreatorCray не палит.
У тебя чо, по случаю лета перегрев?

Здравствуйте, CreatorCray, Вы писали:

I>>Тогда понятно, почему рефакторинг у CreatorCray не палит.
CC>У тебя чо, по случаю лета перегрев?

И не только у него. Какая то массовая эпидемия неадеквата последние пару дней.

Здравствуйте, CreatorCray, Вы писали:

I>>вижла в 2003м была 32х битная, а это значит 2гб на процесс и кердык.
CC>Не вижу связи. У меня до сих пор вижуалка 32битная

Ее 64-битной вообще в природе не бывает и в обозримом будущем не будет.

Здравствуйте, alex_public, Вы писали:

НС>>И чего в последние лет 5 в топовых процессорах архитектурного внедрили?
_>Различные новые инструкции (AVX, AES и т.п.),

Это не архитектурное, а экстенсивное развитие. Покрываем все более экзотические юзкейсы.

_> оптимизация работы с памятью (более эффективные кэши и т.п.).

Это тоже все вылизывание и экстенсивное развитие, ничего архитектурно там не поменялось.

_>Это из того, что с ходу вспомнилось. Думаю что если сесть и специально разбираться, то ещё много разных мелочей накопается.

А речь то не про мелочи.

CS>Ну наконец-то, прозрел. Т.е. ты только что сказал буквально следующе "DDB это память" и "только BitBlt и AplphaBlend аппаратно ускоряются".
CS>Все остальные GDI функции — чисто CPU rasterization.
CS>Т.е. "offload вычислений с CPU" это не про GDI, этим занимаются DirectX, OpenGL, Vulcan, Metal и иже с ними.
Полный список я приводил. Код драйверов который я приводил включает в себя и DrvLineTo, DrvTextOut и многие другие вызовы, которые отправляются на рендеринг в GPU, а не в соответствующие Eng* вызовы.
К сожалению, учитывая полное отсутствие интереса к драйверам которые я указал (их никто даже не скачивал), прихожу к выводу что тебе не интересен предмет спора вообще в принципе, тебе лишь интересно отстоять свои неверные утверждения. И это печально.

CS>(На самом деле полный список: BitBlts, AlphaBlend, TransparentBlt, and StretchBlt)
Этот список валиден только на семерке.
было так
1) На ХР Вначале ускорялось вообще все. Список (не полный кстати) тут внизу: https://docs.microsoft.com/en-us/windows-hardware/drivers/display/hooking-versus-punting
2) В Vista выпилили все ускорение из GDI. Хомячки взыли — ужас какая тормозная ось.
3) В семерке вернули ускорение перечисленных тобой функций (причем далеко не всех что ускорялись ранее) — хомячки вздохнули — ну наконец-то, опять не тормозная ось. Ну а чтоб остальное начало опять работать быстро — надо юзать новые АПИ. А это значит — ставить новый браузер, новый офис. Ну и новые гуи либки, которые поддерживают эти новые АПИ, например твою.
Заметь, я не спорю что новые АПИ лучше и правильнее чем старые GDI вызовы, и предоставляют больший функционал. Печально то, что продвижение этого функционала идет такими типово-маркетинговыми приемами, в результате чего винда становится крайне непредсказуемой платформой, наследуя таким образом худшее от линукса. А линукс меж тем потихоньку наследует лучшее от винды.

Здравствуйте, ononim, Вы писали:

O>К сожалению, учитывая полное отсутствие интереса к драйверам которые я указал (их никто даже не скачивал), прихожу к выводу что тебе не интересен предмет спора вообще в принципе, тебе лишь интересно отстоять свои неверные утверждения. И это печально.

Модель драйверов что была в Windows XP умерла 10 лет назад. Поэтому причем тут "сожаление"? Никому не интересно, померла так померла.
То что драйверы могли переопределять DrvLineTo (single pixel line drawing) не означает a) что эта функция была hardware accelerated и b) что GDI её вообще использовала (см. CreatePen).

В актуальных ОС GDI не accelerated (в том смысле что в это вкладывается сейчас в DirectX, OpenGL, etc). С этим ты согласен?

CS>Модель драйверов что была в Windows XP умерла 10 лет назад. Поэтому причем тут "сожаление"? Никому не интересно, померла так померла.
CS>В актуальных ОС GDI не accelerated (в том смысле что в это вкладывается сейчас в DirectX, OpenGL, etc). С этим ты согласен?
С этим да. Но топик-то — исторический.

Здравствуйте, c-smile, Вы писали:

CS>>>У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти.
_>>Безусловно его нет. Более того, если бы обмен данными между обычной памятью и видео-памятью происходил с помощью инструкций CPU, то это было бы катастрофически медленно. Однако в CPU (и не только — сейчас это уже даже в копеечных МК присутствует) имеется такой механизм работы с периферией как DMA, который позволяет периферийным устройствам обмениваться с памятью процессора в фоне (без его прямых команд). Соответственно при включение этого механизма запись в определённые разделы оперативной памяти по сути полностью аналогична записи в видео-память. И думаю что большинство участников дискуссии имели в виду именно это, просто не расшифровывая очевидные детали.
CS>Всё верно, только оппоненты в дискуссии имели в виду именно "DDB это video память" и "GDI hardware accelerated".
CS>Я же говорю (и MSDN) что у GDI hardware accelerated только BitBlt (фактически это и есть DMA).
CS>Также я говорю (и Фень Юань) что DDB это область RAM а не video RAM. То есть DDB это и есть твои "определённые разделы оперативной памяти".
CS>Вышеизложенное означает что GDI в принципе не может иметь per primitives hardware accelerated drawing.

Нуу насчёт в принципе не может — это спорный вопрос. ) Но если говорить насчёт GDI в винде, то наверное так и есть. Во всяком случае я не припомню информации насчёт их аппаратного ускорения.

CS>Т.е. DrawLine(hdc, ...) это банальный Брезенхем исполняемый CPU и изменяющий RAM. Т.е. этот механизм есть O(N) где N это количество пикселей на экране. Т.е. sucks on high-dpi monitors.
CS>В Direct2D, DirectX, OpenGL же DrawLine() это (условно) посылка quad (четырех координат) на GPU для отрисовки его процессорами (shaders, etc).
CS>Т.е. этот механизм для CPU есть O(1) complex — на зависит от размера экрана.

С Direct2D я не знаком на практике, но если говорить о рисование через шейдеры, то там вывод линии тоже является далеко не тривиальной операцией типа вызова функции LineTo. )))

Здравствуйте, ononim, Вы писали:

CS>>>У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти.
_>>Безусловно его нет. Более того, если бы обмен данными между обычной памятью и видео-памятью происходил с помощью инструкций CPU, то это было бы катастрофически медленно. Однако в CPU (и не только — сейчас это уже даже в копеечных МК присутствует) имеется такой механизм работы с периферией как DMA, который позволяет периферийным устройствам обмениваться с памятью процессора в фоне (без его прямых команд). Соответственно при включение этого механизма запись в определённые разделы оперативной памяти по сути полностью аналогична записи в видео-память. И думаю что большинство участников дискуссии имели в виду именно это, просто не расшифровывая очевидные детали.
O>"Как DMA" — это называется bus mastering, который подвид DMA, позволяющий устройствам напрямую работать с памятью. Но речь не про него, а про memory-mapped space, которое фактически мапит IO порты на АП физической памяти и позволяет CPU инструкциям работы с памятью общаться с девайсом _без_ реального использования физической памяти. DMA тут вообще никаким боком не относится. Работает, разумеется, медленее чем доступ к локальной физической памяти, и работая с таким отображением надо отдавать себе в этом отчет. Кэширование там есть, но минимальное.
O>Замечу, что bus-mastering активно используется встройками которые не имеют своей видеопамяти и таким образом юзают системную память, в том числе и для фреймбуфера. Но речь, повторюсь, не про этот usecase.

Вообще то как раз именно это и называют DMA: https://www.khronos.org/opengl/wiki/Pixel_Buffer_Object. )))

Что же касается портов ввода/вывода и прерываний, то они безусловно так же имеются в PCI, только не очень понятно какое это имеет отношение к обсуждаемой теме. )

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>И чего в последние лет 5 в топовых процессорах архитектурного внедрили?
_>>Различные новые инструкции (AVX, AES и т.п.),
НС>Это не архитектурное, а экстенсивное развитие. Покрываем все более экзотические юзкейсы.
_>> оптимизация работы с памятью (более эффективные кэши и т.п.).
НС>Это тоже все вылизывание и экстенсивное развитие, ничего архитектурно там не поменялось.
_>>Это из того, что с ходу вспомнилось. Думаю что если сесть и специально разбираться, то ещё много разных мелочей накопается.
НС>А речь то не про мелочи.

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

Здравствуйте, alex_public, Вы писали:

CS>>Т.е. DrawLine(hdc, ...) это банальный Брезенхем исполняемый CPU и изменяющий RAM. Т.е. этот механизм есть O(N) где N это количество пикселей на экране. Т.е. sucks on high-dpi monitors.
CS>>В Direct2D, DirectX, OpenGL же DrawLine() это (условно) посылка quad (четырех координат) на GPU для отрисовки его процессорами (shaders, etc).
CS>>Т.е. этот механизм для CPU есть O(1) complex — на зависит от размера экрана.

_>С Direct2D я не знаком на практике, но если говорить о рисование через шейдеры, то там вывод линии тоже является далеко не тривиальной операцией типа вызова функции LineTo. )))

Для нарисовать линию нужно послать команду DrawQuad(p1,p2,p3,p4) и GPU её отобразит. Как — это другой вопрос, главное что для CPU эта инструкция O(1) complex — не зависит от DPI (плотности и кол-ва пикселей).

Здравствуйте, c-smile, Вы писали:

_>>С Direct2D я не знаком на практике, но если говорить о рисование через шейдеры, то там вывод линии тоже является далеко не тривиальной операцией типа вызова функции LineTo. )))
CS>Для нарисовать линию нужно послать команду DrawQuad(p1,p2,p3,p4) и GPU её отобразит. Как — это другой вопрос, главное что для CPU эта инструкция O(1) complex — не зависит от DPI (плотности и кол-ва пикселей).

Ну подскажи точное название этой самой функции скажем в современном OpenGL... )

Здравствуйте, alex_public, Вы писали:

_>Ну подскажи точное название этой самой функции скажем в современном OpenGL... )

GLfloat vertices[] = {-1, -1, 0, // bottom left corner
                      -1,  1, 0, // top left corner
                       1,  1, 0, // top right corner
                       1, -1, 0}; // bottom right corner

GLubyte indices[] = {0,1,2, // first triangle (bottom left - top left - top right)
                     0,2,3}; // second triangle (bottom left - top right - bottom right)

glVertexPointer(3, GL_FLOAT, 0, vertices);
glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_BYTE, indices);

http://www3.ntu.edu.sg/home/ehchua/programming/opengl/cg_introduction.html

А вообще рекомендую глянуть на NanoVG, там все в общем-то тривиально.

Здравствуйте, c-smile, Вы писали:

_>>Ну подскажи точное название этой самой функции скажем в современном OpenGL... )
CS>

CS>GLfloat vertices[] = {-1, -1, 0, // bottom left corner
CS>                      -1,  1, 0, // top left corner
CS>                       1,  1, 0, // top right corner
CS>                       1, -1, 0}; // bottom right corner

CS>GLubyte indices[] = {0,1,2, // first triangle (bottom left - top left - top right)
CS>                     0,2,3}; // second triangle (bottom left - top right - bottom right)

CS>glVertexPointer(3, GL_FLOAT, 0, vertices);
CS>glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_BYTE, indices);
CS>

Функция glVertexPointer давно не входит в современный OpenGL, так что этот код банально не будет работать при использование контекста актуального OpenGL (а в современных версиях opengl, типа webgl, её и не было от рождения).

Но даже если бы он предположим работал (скажем мы ограничимся десктопом и будем запрашивать устаревшую версию OpenGL) и мы использовали бы убранный из стандарта предопределённый атрибут gl_Vertex, то где собственно код самого шедейра, а так же код его загрузки, компиляции, линковки и активации? )

CS>http://www3.ntu.edu.sg/home/ehchua/programming/opengl/cg_introduction.html

glBegin в 2017-ом году? Серьёзно?

CS>А вообще рекомендую глянуть на NanoVG, там все в общем-то тривиально.

Да я как бы и сам без проблем могу написать функцию, рисующую линию на экране с помощью opengl, но тривиальной она не будет в любом случае.

P.S. Кстати, по твоему коду: вполне можно использовать и двухмерные координаты (при подходящем шейдере) и рисовать всего 4 точки (TRIANGLE_STRIP). Но это уже так, мелкое замечание, не влияющее на суть дискуссии. )))

Здравствуйте, CreatorCray, Вы писали:

I>>Рефакторинг в твоём случае ограничен перформансом IDE. И рефакторинг вобщем глобальный инструмент. Локально можно побороть проблему десятком разных способов, хоть взять влоб да переписать.
CC>А нельзя ли выражать свои мысли яснее?

Если рефакторинг работает долго, как ты сказал, то смысла в ём нет. Это вроде бы понятно

I>>вижла в 2003м была 32х битная, а это значит 2гб на процесс и кердык.
CC>Не вижу связи. У меня до сих пор вижуалка 32битная

Всего 5 лет назад было модным "ускорять" MS VS путём включения флажка largeaddressaware. Это доступно только если OS — 64 бита.

I>>SSD массово начали ставить совсем недавно. в 2003м SSD даже у гиков не было.
CC>Опять таки, это тут при чём?

Начинаем сначала: "прорыв в ИДЕ случился благодаря SSD и x64."
Твоя реплика "Угу, году так в 2003м, если не раньше."
И как теперь понимать твои высказывания ?

Кроме того, я сказал ИДЕ, а не MS VS. Idea давно уже 64 бита.

Здравствуйте, CreatorCray, Вы писали:

I>>Тогда понятно, почему рефакторинг у CreatorCray не палит.
CC>У тебя чо, по случаю лета перегрев?

Ты отказываешься от своих слов ?