Как в GDI с наименьшими затратами сдвинуть изображение на несколько точек по горизонтали? Пробовал BitBlt/SRCCOPY на месте (в пределах одного контекста), но оно двигает полосами. Без CreateCompatibleDC, CreateCompatibleBitmap и BitBlt туда-сюда никак?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В смысле? Я сам его рисую — это графики в реальном времени.
Ты ж не непосредственно на окне рисуешь, а через промежуточный буфер? Ну просто иначе у тебя будет портиться изображение при движении окна за край экрана.
Если ты создал промежуточный буфер через CreateDIBSection, то у тебя есть доступ к его памяти.
ЕМ>После заполнения окна надо двигать нарисованное влево, рисуя новое справа.
Кстати, а почему не ОпенГЛ?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Ты ж не непосредственно на окне рисуешь, а через промежуточный буфер?
Непосредственно в окне.
TB>иначе у тебя будет портиться изображение при движении окна за край экрана.
Ничего не портится, и не должно.
TB>Кстати, а почему не ОпенГЛ?
Я вообще с графикой почти никогда не работал — в GDI более-менее ориентируюсь, а от OpenGL только название знаю. И мне это пока сугубо для отладки, так что нужен самый простой метод. Но быстрый, иначе рисование (даже в отдельном потоке) тормозит работу основного кода.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ничего не портится, и не должно.
Эээ, но ведь тебе надо полностью обновлять изображение при некоторых действиях. Если ты этого не делаешь, то будет такой эффект:
Задвинь окно частично за экран, а потом верни обратно. Часть, что была за экраном, заполнится либо фоновым цветом окна (это если ты не заблокировал WM_ERASEBKGND), либо заполнится кашей.
То есть мне кажется, что с промежуточным буфером жизнь намного проще. Насчёт перфоманса тоже есть подозрения, что операции, которые делаются в оперативе, будут намного быстрее, чем операции над пикселями окна.
ЕМ>И мне это пока сугубо для отладки, так что нужен самый простой метод.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>тебе надо полностью обновлять изображение при некоторых действиях.
Так это делает винда, присылая мне при этих действиях WM_PAINT. Мое дело — рисовать график в указанном фрагменте окна.
TB>Если ты этого не делаешь, то будет такой эффект
Он будет, если рисовать как придется. Если как положено — из WM_PAINT, WM_DRAWITEM и т.п., то не будет.
TB>Задвинь окно частично за экран, а потом верни обратно. Часть, что была за экраном, заполнится либо фоновым цветом окна (это если ты не заблокировал WM_ERASEBKGND), либо заполнится кашей.
В таких случаях Window Manager пришлет WM_PAINT для нужной области/областей.
TB>есть подозрения, что операции, которые делаются в оперативе, будут намного быстрее, чем операции над пикселями окна.
Так операции те же самые — один раз прочитать каждую точку, один раз записать ее. Меняются только источник/назначение.
Я вроде подобрал параметры, с которыми BitBlt нормально двигает — у него какие-то проблемы, если в операцию попадает граница окна.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Как в GDI с наименьшими затратами сдвинуть изображение на несколько точек по горизонтали? Пробовал BitBlt/SRCCOPY на месте (в пределах одного контекста), но оно двигает полосами. Без CreateCompatibleDC, CreateCompatibleBitmap и BitBlt туда-сюда никак?
А нафига вы его двигаете. Его надо перерисовывать. Если риует долго разбейте на тайлы и кэшируйте их. Но при WM_PAINT перерисовывайте всё что попадает в запрашиваемую область.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В таких случаях Window Manager пришлет WM_PAINT для нужной области/областей.
Но ведь внутри WM_PAINT ты не знаешь, какие области надо перерисовывать. То есть перерисовываешь всё.
ЕМ>Так операции те же самые — один раз прочитать каждую точку, один раз записать ее. Меняются только источник/назначение.
Есть существенная разница, в каком порядке это делать. BitBlt из памяти на экран — это наверное самая быстрая операция, которая затрагивает все пиксели.
То есть я всё равно не вижу смысла отказываться от промежуточного буфера.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, kov_serg, Вы писали:
_>А нафига вы его двигаете.
Чтоб двигался, а не стоял на месте.
_>Его надо перерисовывать.
Когда надо — перерисовываю. Но это медленно.
_>Если риует долго разбейте на тайлы и кэшируйте их.
Не понял, чем это будет отличаться от сдвига, кроме того, что станет значительно сложнее.
_>при WM_PAINT перерисовывайте всё что попадает в запрашиваемую область.
Здравствуйте, T4r4sB, Вы писали:
TB>внутри WM_PAINT ты не знаешь, какие области надо перерисовывать.
Кто вызывает BeginPaint и получает PAINTSTRUCT, те знают. Кто не вызывает — перерисовывают всё.
TB>BitBlt из памяти на экран — это наверное самая быстрая операция, которая затрагивает все пиксели.
Хм, на досуге сравню, но не вижу причин для разницы в скорости. Это ж не какая-нибудь EGA, где все время нужно переключать плоскости.
Здравствуйте, Евгений Музыченко, Вы писали:
_>>А нафига вы его двигаете. ЕМ>Чтоб двигался, а не стоял на месте.
_>>Его надо перерисовывать. ЕМ>Когда надо — перерисовываю. Но это медленно.
Именно поэтому кешируйте если медленно. А двигать можно просто перерисовывая кэшированные фрагменты.
_>>Если риует долго разбейте на тайлы и кэшируйте их. ЕМ>Не понял, чем это будет отличаться от сдвига, кроме того, что станет значительно сложнее.
Ничего не сложнее просто еще промежуточный класс который этим будет заниматься.
_>>при WM_PAINT перерисовывайте всё что попадает в запрашиваемую область. ЕМ>Само собой.
При этом если вы рисуете тайлами оно само всё клипает.
Здравствуйте, kov_serg, Вы писали:
_>Именно поэтому кешируйте если медленно. А двигать можно просто перерисовывая кэшированные фрагменты.
Ничего не понял. Скорость перерисовки в исключительных случаях (например, когда окно было перекрыто) меня не беспокоит — нужно минимизировать лишь время регулярной отрисовки. Пока графики не заполнили все окно, в каждом вызове WM_PAINT дорисовываются только новые точки. Когда уже заполнил, перед дорисовкой новых точек весь график сдвигается влево. Какая разница, будет он сдвигаться копированием из буфера экрана, или из какого-то дополнительного, "кэшированного", буфера?
_>Ничего не сложнее просто еще промежуточный класс который этим будет заниматься.
"Промежуточный класс" — это не "сложнее"?
_>если вы рисуете тайлами оно само всё клипает.
Оно и так "само все клипает". В упор не вижу разницы.
О, спасибо! Очередное подтверждение тому, что виндовая документация убога — функций ScrollDC, ScrollWindow, ScrollWindowEx нет в общем списке функций GDI, только в разделе Scroll Bars, хотя напрямую оно никак не связано.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ничего не понял. Скорость перерисовки в исключительных случаях (например, когда окно было перекрыто) меня не беспокоит — нужно минимизировать лишь время регулярной отрисовки. Пока графики не заполнили все окно, в каждом вызове WM_PAINT дорисовываются только новые точки. Когда уже заполнил, перед дорисовкой новых точек весь график сдвигается влево. Какая разница, будет он сдвигаться копированием из буфера экрана, или из какого-то дополнительного, "кэшированного", буфера?
Разница огромная.
_>>Ничего не сложнее просто еще промежуточный класс который этим будет заниматься. ЕМ>"Промежуточный класс" — это не "сложнее"?
Нет каждый класс самодостаточен и не связан с остальными. Добавление промежуточного кэширующего слоя не должно влиять на сложность отрисовки, тот кто рисует вообще ого существовании не догадывается.
_>>если вы рисуете тайлами оно само всё клипает. ЕМ>Оно и так "само все клипает". В упор не вижу разницы.
Графики бывают разные сотни точек и миллионы точек. Подходы будут разные для разных уровней детализации.
Если у вас рисует медленно значит точек много и скорей всего рисуете как есть.
Здравствуйте, kov_serg, Вы писали:
_>Разница огромная.
Это все, что Вы можете сказать по сути заданных вопросов?
_>Добавление промежуточного кэширующего слоя не должно влиять на сложность отрисовки
Даже если этот класс где-то существует в готовом виде, уже заточенный под мои потребности, мне придется, как минимум, ознакомиться с его интерфейсом, привязаться к нему, вставить его в текстовом виде или обеспечить линковку. Если же его не существует, мне придется его спроектировать, написать, отладить, а затем сделать с ним все, перечисленное выше. Если, по-Вашему, это не меняет уровень сложности моего кода, то как Вы определяете для себя понятие "сложность"?
_>Если у вас рисует медленно значит точек много
Еще раз, для тех, кому лень вчитаться в уже написанный текст: рисует быстро, перерисовывает медленно, если для сдвига влево использовать полную перерисовку, которая даже идеологически для этой цели некорректна.
Здравствуйте, Евгений Музыченко, Вы писали:
TB>>внутри WM_PAINT ты не знаешь, какие области надо перерисовывать.
ЕМ>Кто вызывает BeginPaint и получает PAINTSTRUCT, те знают. Кто не вызывает — перерисовывают всё.
Те, кто не вызывает, пользуются GetUpdateRect()
TB>>BitBlt из памяти на экран — это наверное самая быстрая операция, которая затрагивает все пиксели.
ЕМ>Хм, на досуге сравню, но не вижу причин для разницы в скорости. Это ж не какая-нибудь EGA, где все время нужно переключать плоскости.
Разницы в скорости нет, но двойной буфер избавляет от мельтешения на экране, когда таскаешь чужое окошко поверх своего или ресайзишь окно.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну да, уже посоветовали. Были б эти функции в общем списке GDI functions — давно б сам нашел.
Нашёл ниже только ScrollDC. ScrollWindow тебе ещё и правильно окно инвалидирует так, что тебе надо будет перерисовать только новую область без изображения, которая возникла после сдвига.
Здравствуйте, Евгений Музыченко, Вы писали:
_>>Его надо перерисовывать.
ЕМ>Когда надо — перерисовываю. Но это медленно.
У вас чтото странное. В 9м году я делал так плавный быстрый скроллинг дотнете и все было быстро, гладко.
_>>Если риует долго разбейте на тайлы и кэшируйте их.
ЕМ>Не понял, чем это будет отличаться от сдвига, кроме того, что станет значительно сложнее.
Где именно вы видите сложность? У вас ровно один тайл.
Здравствуйте, Pauel, Вы писали:
P>В 9м году я делал так плавный быстрый скроллинг дотнете и все было быстро, гладко.
И параллельно у Вас работал звуковой поток с буферизацией в единицы миллисекунд? Если всю мгновенную производительность процессора отдать на перерисовку, у меня тоже все "быстро, гладко", только поток трещит.
P>Где именно вы видите сложность?
В добавлении совершенно лишних сущностей и кода/данных для их обслуживания.
Здравствуйте, Евгений Музыченко, Вы писали:
P>>В 9м году я делал так плавный быстрый скроллинг дотнете и все было быстро, гладко.
ЕМ>И параллельно у Вас работал звуковой поток с буферизацией в единицы миллисекунд? Если всю мгновенную производительность процессора отдать на перерисовку, у меня тоже все "быстро, гладко", только поток трещит.
Смешной аргумент. Думаете 14 лет назад процы быстрее были, да на тормозном на тот момент дотнете?
Это конкретно ваше решение пожирает процессор. В норме такого быть не должно.
P>>Где именно вы видите сложность?
ЕМ>В добавлении совершенно лишних сущностей и кода/данных для их обслуживания.
Эти "совершенно лишние" сущности уменьшают потребление процессора до нуля.
Здравствуйте, Pauel, Вы писали:
P>Эти "совершенно лишние" сущности уменьшают потребление процессора до нуля.
Вы пробовали читать то, что я пишу, или ориентируетесь исключительно на отдельные слова?
Еще раз, медленно, с расстановкой:
— При отрисовке графика по ходу работы потока (по одной точке каждой величины за цикл) потребление процессора меньше 1%, отрисовка не мешает работе звукового потока.
— При сдвиге графика с помощью BitBlt или ScrollWindow, и последующей отрисовке одного комплекта точек потребление процессора меньше 1%, отрисовка не мешает работе звукового потока.
— При поточечной перерисовке всего графика при каждом сдвиге в окне из нескольких сотен точек по каждому измерению (это около сотни раз в секунду) потребление процессора возрастает до 25-30% и начинает мешать работе звукового потока.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>- При поточечной перерисовке всего графика при каждом сдвиге в окне из нескольких сотен точек по каждому измерению (это около сотни раз в секунду) потребление процессора возрастает до 25-30% и начинает мешать работе звукового потока.
Потому что ты неправильно делаешь поточечную перерисовку. Если выводить по точкам в промежуточный буфер (нет, не через SetPixel, а через buffer.memory[x + y * buffer.stride] = color, а потом на экран за один BitBlt, то это будет ничуть не медленнее и технически намного проще.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Если выводить по точкам в промежуточный буфер (нет, не через SetPixel
Я использую не SetPixel, а MoveToEx/LineTo, поскольку масштаб может меняться, и точки графика могут не соответствовать точкам экрана.
TB>а через buffer.memory[x + y * buffer.stride] = color, а потом на экран за один BitBlt, то это будет ничуть не медленнее
Если б я это делал для релиза, и нужно было обеспечить быструю перерисовку при перекрытии окон, то рисовал бы линиями в Memory DC, чтоб не делать линии вручную, а перерисовку фрагмента делал бы через BitBlt.
TB>и технически намного проще.
Только в ситуации, когда точка графика соответствует точке экрана.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если б я это делал для релиза, и нужно было обеспечить быструю перерисовку при перекрытии окон, то рисовал бы линиями в Memory DC, чтоб не делать линии вручную, а перерисовку фрагмента делал бы через BitBlt.
Ну да, как-то так, разве это не проще?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>- При поточечной перерисовке всего графика при каждом сдвиге в окне из нескольких сотен точек по каждому измерению (это около сотни раз в секунду) потребление процессора возрастает до 25-30% и начинает мешать работе звукового потока.
ЕМ>Как еще нужно объяснить, чтоб стало понятно?
Читайте себя выше. Не совсем ясно, зачем вы сотни раз в секунду чего то выводите. У вас цель процессор съесть?
Для плавности хватит 50 раз в секунду или даже чуть меньше. Все остальное — лишнее.
Поточечно нужно выводить только новую часть. Остальное шлепается из буфера.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если б я это делал для релиза, и нужно было обеспечить быструю перерисовку при перекрытии окон, то рисовал бы линиями в Memory DC, чтоб не делать линии вручную, а перерисовку фрагмента делал бы через BitBlt.
Тогда непонятен ваш начальный вопрос. Выглялит, так будто вы знаете оптимальный вариант, и просите подсказать субоптимальный
TB>>и технически намного проще.
ЕМ>Только в ситуации, когда точка графика соответствует точке экрана.
Это лечится трансформацией координат и перерисовкой при изменении масштаба
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>О, спасибо! Очередное подтверждение тому, что виндовая документация убога — функций ScrollDC, ScrollWindow, ScrollWindowEx нет в общем списке функций GDI, только в разделе Scroll Bars, хотя напрямую оно никак не связано.
Здравствуйте, Евгений Музыченко, Вы писали:
_>>Добавление промежуточного кэширующего слоя не должно влиять на сложность отрисовки ЕМ>Даже если этот класс где-то существует в готовом виде, уже заточенный под мои потребности, мне придется, как минимум, ознакомиться с его интерфейсом, привязаться к нему, вставить его в текстовом виде или обеспечить линковку. Если же его не существует, мне придется его спроектировать, написать, отладить, а затем сделать с ним все, перечисленное выше. Если, по-Вашему, это не меняет уровень сложности моего кода, то как Вы определяете для себя понятие "сложность"?
o_O ? если вам лень возьмите готовые библиотеки отрисовки графиков.
_>>Если у вас рисует медленно значит точек много ЕМ>Еще раз, для тех, кому лень вчитаться в уже написанный текст: рисует быстро, перерисовывает медленно, если для сдвига влево использовать полную перерисовку, которая даже идеологически для этой цели некорректна.
Что значит перерисовывает. С тайлами можно рисовать в фоне и в разных потоках. И не перерисовывать то что не изменялось. А в WM_PAINT уже рисовать быстро, уже подготовленные участки или если еще не готовы можно рисовать заглушки.
Здравствуйте, Pavel Dvorkin, Вы писали:
ЕМ>>функций ScrollDC, ScrollWindow, ScrollWindowEx нет в общем списке функций GDI
PD>Потому что это не wingdi, а winuser
Речь не о "функциях, реализованных в gdi32.dll" (по этому признаку вообще нет смысла что-либо группировать), а о "функциях, относящихся к отрисовке", "функциях, работающих с графикой/изображениями" и т.п.
Почему, например, SetPixel включена в список "bitmap functions", а ScrollDC — нет? Обе работают с контекстами и манипулируют пикселами. По уму, должен быть полный список функций по принадлежности, например, к работе с контекстами. В том же MFC ScrollDC включена в класс HDC, что вполне логично.
, чтобы наблюдать за параметрами потока реального времени. Графики выводятся в темпе изменения состояния потока. Поэтому код может быть сколь угодно корявым и примитивным — главное, чтоб он был быстрым.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему, например, SetPixel включена в список "bitmap functions", а ScrollDC — нет? Обе работают с контекстами и манипулируют пикселами. По уму, должен быть полный список функций по принадлежности, например, к работе с контекстами. В том же MFC ScrollDC включена в класс HDC, что вполне логично.
Об этом надо спросить тех, кто делал user и gdi в Windows 1.0 . А потом изменить было уже невозможно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>потом изменить было уже невозможно.
В какой момент стало невозможно добавить в документацию отдельные списки, вроде "device context functions", "functions working with graphics data" и т.п.? Да хоть включить ScrollDC в Bitmap Functions, ей там самое место.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В какой момент стало невозможно добавить в документацию отдельные списки, вроде "device context functions", "functions working with graphics data" и т.п.? Да хоть включить ScrollDC в Bitmap Functions, ей там самое место.
Так в отдельный список и добавлено. Но не в тот список
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так в отдельный список и добавлено. Но не в тот список
А как найти-то? Я ж подчеркивал, что по словам "move" или "shift" найти нереально. Более того, во многих дискуссиях, которые находятся по этим словам, обсуждается та же задача, что и у меня, но отсылок к ScrollDC/ScrollWindow там нет. По-моему, это показатель качества и связности документации.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А как найти-то? Я ж подчеркивал, что по словам "move" или "shift" найти нереально. Более того, во многих дискуссиях, которые находятся по этим словам, обсуждается та же задача, что и у меня, но отсылок к ScrollDC/ScrollWindow там нет. По-моему, это показатель качества и связности документации.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Поправил предыдущее сообщение, дал линк.
Вы полагаете, что функции в документации должны группироваться прежде всего по заголовкам, в которых они определены? Это действительно наиболее логичный и понятный способ группировки средств API?
Даже если придерживаться этой точки зрения, сохраняется вопрос — как найти в документации ту или иную функцию, про которую лишь приблизительно известно, что она делает?
Вот, например, что это за список? Здесь ни winuser.h, ни wingdi.h не указаны в списке заголовков, приведенных в начале. Если, согласно Вашей концепции, ScrollDC — это "не wingdi, а winuser", то что в этом списке делают BeginPaint/EndPaint, DrawAnimatedRects, DrawCaption и прочие, которые определены в winuser.h? А если в этот список собраны функции, относящиеся к работе с изображениями, то почему в нем нет ScrollDC?
Здравствуйте, Евгений Музыченко, Вы писали:
_>>если вам лень возьмите готовые библиотеки отрисовки графиков. ЕМ>Типа, разбираться в интерфейсах и особенностях подключения мне должно быть не лень?
Вам шашечки или поибаццца? Если второе то флаг вам в руки. Всё равно придёте к тайлам.
ЕМ>Блин, два человека на всю тему дали дельные советы, остальные развели дискуссию не пойми о чем...
Ой горе беда огорчение. Вообще-то никто не обещал что бесплатные советы будут дельными
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вы полагаете, что функции в документации должны группироваться прежде всего по заголовкам, в которых они определены? Это действительно наиболее логичный и понятный способ группировки средств API?
Ну как один из способов, да. 100% надежного разделения все равно не добиться — пересечения есть. Тот же ScrollDC скорее я бы отнес с GDI, но он почему-то в USER. Почему — не знаю, может, потому что близок к ScrollWindow, а это точно USER
ЕМ>Даже если придерживаться этой точки зрения, сохраняется вопрос — как найти в документации ту или иную функцию, про которую лишь приблизительно известно, что она делает?
Ну вообще-то когда приблизительно известно, что нужно от функции (я бы так сформулировал судя по исходному сообщению), что как искать — бог знает.
ЕМ>Вот, например, что это за список? Здесь ни winuser.h, ни wingdi.h не указаны в списке заголовков, приведенных в начале. Если, согласно Вашей концепции, ScrollDC — это "не wingdi, а winuser", то что в этом списке делают BeginPaint/EndPaint, DrawAnimatedRects, DrawCaption и прочие, которые определены в winuser.h? А если в этот список собраны функции, относящиеся к работе с изображениями, то почему в нем нет ScrollDC?
Это вообще-то GDI, о чем ясно сказано в заголовке. А то, что здесь присутствуют функции, которые из USER формально — ну так я уже написал, нельзя строго разделить. А почему именно так разделили — тоже писал, надо спросить авторов Windows 1.0
Здравствуйте, Pavel Dvorkin, Вы писали:
ЕМ>>Вы полагаете, что функции в документации должны группироваться прежде всего по заголовкам, в которых они определены?
PD>Ну как один из способов, да.
Для кого/чего может быть полезен такой способ группировки? Он не несет никакой дополнительной информации сверх содержимого самого заголовка, разве что подает его в чуть более удобной форме. Но и это избыточно, поскольку заголовок, который нужно включить для использования функции, всегда указан в ее описании. Тогда зачем? По сути, это как комментарии вроде "i++; // увеличиваем i на единицу".
PD>100% надежного разделения все равно не добиться — пересечения есть.
Для чего стоило бы добиваться "100% надежного разделения"? Правильнее было бы создать несколько списков, с разными способами группировки. А еще лучше — присвоить каждой функции/структуре тэги — window, DC, rectangle, line, shape, curve, pen, brush и т.п. Но документация, как известно, никогда не была сильной стороной MS.
PD>Тот же ScrollDC скорее я бы отнес с GDI, но он почему-то в USER. Почему — не знаю, может, потому что близок к ScrollWindow, а это точно USER
Про разделение KERNEL/USER/GDI нужно было забыть еще лет тридцать назад, и начать группировать по свойствам.
ЕМ>Но документация, как известно, никогда не была сильной стороной MS.
хаха, это если в линуксовые доки никогда не смотреть... Да и эпловские тоже далеко не идеал.
Как много веселых ребят, и все делают велосипед...
И мне это пока сугубо для отладки, так что нужен самый простой метод. Но быстрый, иначе рисование (даже в отдельном потоке) тормозит работу основного кода.
