Можно ли заблокировать участок памяти при использовании потоков?
Чтобы до определенного момента этот участок не использовался другими потоками.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).aspx

Только не понятно, что это тебе даст

> Можно ли заблокировать участок памяти при использовании
> потоков?


EnterCriticalSection/LeaveCriticalSection

Управление памятью выполняется на уровне процесса, а не потока

>EnterCriticalSection/LeaveCriticalSection
Не то немного.

Тут суть в том, что нужно дождаться выполнения BitBlt и установить флаг окончания вывода. Потоки очень шустрые ребята и портят мне картинку в момент если стопроцентно не дождаться окончания вывода буфера. Поэтому этот кусок памяти надо защитить или установить какой-то маркер, подтверждающий окончание вывода.
Может пиксел в конце рисовать определенного цвета и проверять есть ли он на DC или нет? Вот думаю как сделать лучше. Сейчас стоит логический флаг. В принципе работает, но иногда проскакивают полоски из-за асинхронности. Вид портят.
Может копировать в другой буфер в момент протекции и рисовать из него? В приницпе скорость позволяет. В общем буду вечером пробовать.

Чтобы было понятнее опишу ситуацию детальнее: потоки рисуют со скоростью ~600 fps, а BitBlt крайне медленна. Поэтому потоки портят изображение еще до окончания вывода.
Вот думаю может Direct2D может помочь? Там вроде даже вертикальная синхронизация есть. Никто не пробовал Direct2D?

> Поэтому потоки портят изображение еще до окончания вывода.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd144844(v=vs.85).aspx

han_malign ©   (15.01.18 18:03) [5]
В 10-ку! То что нужно :) Спасибо!

> dmk ©   (15.01.18 19:17) [6]

это не то что нужно, https://msdn.microsoft.com/en-us/library/windows/desktop/ms684256(v=vs.85).aspx


> Там вроде даже вертикальная синхронизация есть.

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


> потоки рисуют со скоростью ~600 fps, а BitBlt крайне медленна

для вывода можно использовать двойную буферизацию, front/back buffer.


> Никто не пробовал Direct2D?
>
>

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

Eraser ©   (16.01.18 12:14) [7]
>это не то что нужно
Да сделал уже. GdiFlush сразу очередь GDI освобождает не позволяя вмешаться другим потокам в буфер. Тем более все это обернуто в CriticalSection. Механизм параллельности у меня работает. Даже потоки на ходу можно отключать/включать для повышения производительности. Я бы дал ссылочку, но ИШ прибъет :)

>при чем тут вертикальная синхронизация
В GDI ее просто нет, а очень бы хотелось. Просто мысли вслух.

>для вывода можно использовать двойную буферизацию, front/back buffer.
Так и сделано. Пока один буфер выводится, в другом уже рисуется новый кадр.

>конечно пробовал
А там свой буфер доступен как в CreateDIBSection ?

> dmk ©   (16.01.18 18:31) [8]


> Тем более все это обернуто в CriticalSection

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


> А там свой буфер доступен как в CreateDIBSection ?

там несколько способов, на сколько я помню. например
https://msdn.microsoft.com/ru-ru/library/windows/desktop/dd371150(v=vs.85).aspx

но, любые пересечения с CPU - удар по производительности, лучше рисовать средствами самого Direct2D, как можно реже прибегая к маппингу в основную память том или ином виде.

>как можно реже прибегая к маппингу в основную память том или ином виде
У меня CPU-render. Вся математика своя. В этом и суть. Нужен прямой доступ к памяти.
Так бы я OpenGL использовал и делов то.

>любые пересечения с CPU - удар по производительности
Да не. Современные CPU тянут уже как одни из самых первых видюх.
У меня Core-i7 6950X Extreme Broadwell 3.4 ГГц. Одно ядро как Voodoo 3 2000 примерно тянет. По совокупной производительности 10 ядер думаю побить по производительности Voodoo 5 6000 (Правда без AA). Беда в том, что у CPU очень маленькая пропускная способность памяти. Мне удалось добиться что-то около 5-6 Гб/с под Win10 x64.
Это полность текстурированная сцена (16k полигонов) 2560x1600 при ~19-20 fps + динамическое диффузное освещение. Так тянет одно ядро. Все 10 ядер тянут ~38-40 fps при 600к полигонов. Потолок для шины. CPU тянет, а пропускная способность памяти низкая. Если снизить до 300к полигонов, то 2560x1600 при ~60 fps ;) Прям пропорция 1 к 2.

> > А там свой буфер доступен как в CreateDIBSection ?
> там несколько способов, на сколько я помню. например

https://msdn.microsoft.com/en-us/library/windows/desktop/bb174565(v=vs.85).aspx
- только надо помнить, что оно не всегда DXGI_FORMAT_B8G8R8A8_UNORM

GetDisplaySurfaceData это что-то типа glReadPixels. Прямого доступа к памяти нет.
Просто фреймбуфер из видеопамяти копируется. А свой буфер скинуть возможности нет.

>Он же пояснял - нельзя ссылочки на exe-шники.
Ссылок на EXE не было. По ссылке шел переход на mail.ru,
а там уже предоставлялся выбор - скачивать/не скачивать мой RAR-архив.
Касперский у меня уже лет 15 лицензионный. Вирусов не было за это время. Ни одного.
Delphi - лицензия. У меня вообще на все лицензия.
Хостинг Delphimaster от моего EXE не пострадал :)

> dmk ©

посмотри класс TCanvasD2D (FMX.Canvas.D2D), там полно работающего кода.

>Вы вроде совсем не планируете исходники выкладывать?
Так еще нечего выкладывать. Пока первые результаты. Движок на стадии разработки.
Из альтернатив есть открытые исходнкики Quake/Doom. У меня пока не очень здоровый каркас :)

> GetDisplaySurfaceData это что-то типа glReadPixels. Прямого доступа к памяти нет.
> Просто фреймбуфер из видеопамяти копируется. А свой буфер скинуть возможности нет.

- это одно из применений, читать нынче можно только из ресурса с D3D11_USAGE_STAGING в который GPU можно попросить что-то скопировать...
DXGI(Surface) - базовый механизм(в основном где-то внутрях), копать надо отсюда:
D3D11CreateDevice[AndSwapChain]()
ID3D11Device::CreateTexture2D({D3D11_TEXTURE2D_DESC::Usage = D3D11_USAGE_...})
и вот тут как раз оно(то что во всех остальных справках считается уже must know):
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476259(v=vs.85).aspx

а под W10 - появилась еще более прикольная вещь
ID3D11Device3::ReadFromSubresource()/ID3D11Device3::WriteToSubresource()

З.Ы. я просто пока еще сам копаю, применительно как раз к захвату...