вопрос по DC

[arechemist]

Как можно работать с DC и что и как в него можно записывать и как его использовать?

[Faust]

Если Вы ещё не обзавелись программой API-Guide, то скачайте её или какой-нибудь справочник по API с примерами (линков на форуме великое множество). Записывать желательно графическую информацию - используйте поиск по ключевым словам BitBlt, StretchBlt, TransparentBlt...

[tyomitch]

А что нужно-то? Что-то конкретное, или просто так?

[arechemist]

tyomitch
Да вот просмотрел статью про BitBlt, а там новые созданные DC использовались, совместные с пикчурбоксами, но пример из статьи не работал... Вроде написано, что DC работают гораздо быстрее чем обычные пикчурбоксы... Так вот хочу научиться их создавать ...

[tyomitch]

Покажи статью - посмотрим пример, работает или нет. Заодно и объясним что-то, если непонятно.
Пока непонятно только, что тебе нужно. Пользоваться DC вместо PictureBox-ов?

А создавать их просто: CreateCompatibleDC (Form1.hDC)

[arechemist]

Что делают в этой статье функции:
CreateCompatibleBitmap
DeleteObject
SelectObject
Зачем они нужны

ps а что за API-Guide и где его скачать?

[GSerg]

www.allapi.net aka www.mentalis.org

[arechemist]

А на русском такой шняги про АПИ нет?

[alibek]

Шняги сколько угодно, но нормальная документация в MSDN и на английском

[tyomitch]

Что делают в этой статье функции:
CreateCompatibleBitmap
DeleteObject
SelectObject
Зачем они нужны

Я чего-то не догоняю . О какой статье идёт речь?

В общем: CreateCompatibleBitmap создаёт картинку, DeleteObject её удаляет, SelectObject выбирает её в DC. Более конкретно - когда покажешь статью.

ps а что за API-Guide и где его скачать?

http://www.mentalis.org/agnet/apiguide.shtml

[arechemist]

вот эта статья. http://www.vbstreets.ru/VB/Articles/65569.aspx
Расскажите поподробнее что делают функции объявленные в этой статье( ну кроме BitBlt. Тут все ясно )

[GSerg]

Хм... Ну ладно
DeviceContext – это структура, формат которой объявлен закрытым с целью безболезненного изменения его в будущем. Для работы с этой структурой используются только специальные функции и никогда – напрямую.
Главное в DC – его содержимое. В изначально созданном DC ничего нет. Чтобы работать, нужно создать ещё и графические объекты, после чего создать логическую связь оных с DC (это называется «выбрать в DC», занимается этим функция SelectObject). Одновременно в одном DC может находиться только один объект данного типа (один битмап, одна кисть, одно перо...). При этом в случае с битмапом зависимость взаимно однозначная: если битмап выбран в DC, то он не может быть выбран в другой DC.
В общем случае работа с DC выглядит так: есть некий уже существующий DC, работать с которым мы хотим. При помощи CreateCompatibleDC мы создаём новый DC, совместимый со старым. Битмапа в нём пока нет, просто пустышка нулевого размера. Создаём битмап (CreateCompatibleBitmap) и выбираем его в DC (SelectObject). При этом запоминаем в переменные хэндлы и DC, и битмапа (по окончании работы нужно всё вручную удалять – DeleteDC для DC и DeleteObject для картинки).

[tyomitch]

Хм... Ну ладно
DeviceContext – это структура, формат которой объявлен закрытым с целью безболезненного изменения его в будущем. Для работы с этой структурой используются только специальные функции и никогда – напрямую.
Главное в DC – его содержимое. В изначально созданном DC ничего нет. Чтобы работать, нужно создать ещё и графические объекты, после чего создать логическую связь оных с DC (это называется «выбрать в DC», занимается этим функция SelectObject). Одновременно в одном DC может находиться только один объект данного типа (один битмап, одна кисть, одно перо...). При этом в случае с битмапом зависимость взаимно однозначная: если битмап выбран в DC, то он не может быть выбран в другой DC.
В общем случае работа с DC выглядит так: есть некий уже существующий DC, работать с которым мы хотим. При помощи CreateCompatibleDC мы создаём новый DC, совместимый со старым. Битмапа в нём пока нет, просто пустышка нулевого размера. Создаём битмап (CreateCompatibleBitmap) и выбираем его в DC (SelectObject). При этом запоминаем в переменные хэндлы и DC, и битмапа (по окончании работы нужно всё вручную удалять – DeleteDC для DC и DeleteObject для картинки).

Придерусь, можно? Не нулевого:

Note: When a memory device context is created, it initially has a 1-by-1 monochrome bitmap selected into it

[GSerg]

Можно, можно...

Я не злопамятный. Я просто злой и память у меня хорошая.

Я не злопамятный, у меня просто склероз. Отомщу, забуду - и снова отомщу...

[tyomitch]

Ещё, мне кажется, стоит рассказать про то, зачем вообще нужны DC.
Когда создавалась Винда - а создавалась она не как ОС, а как графическая среда, что-то вроде теперяшнего DirectX - стандартов на видеоадаптеры было очень много; каждый производитель PC-клона пихал в него собственные разработки. Соответственно, графические программы приходилось снабжать десятками разных видеодрайверов (программировавшие под BGI помнят, сколько разных BGI-драйверов поставлялось с BP/BC). Microsoft решила, что она сэкономит много головной боли авторам и много места на дискетах пользователям, если эти видеодрайверы будут в едином формате и в одном экземпляре (а не свой у каждой программы). Под это дело была разработана концепция DC: программист не знает, какова структура под-лежащего устройства, какая там глубина цвета, какое выравнивание строк и т.п. Он просто пишет код, оперируя понятиями "кистей" и "перьев", а ОС сама преобразует их в операции над соответствующим устройством.
Однако, ещё перед релизом Win10 Microsoft сообразила, что одним только SDK программистов к платформе не привлечь, и написала для неё несколько прикладных программ - Реверси (почему-то исчезнувшее ко времени Win31), Блокнот, Пэйнтбраш и т.п. В те времена подобных платформ было немало, и Win10 никакой выдающейся популярности не получила. Однако тяжёлое наследство первых версий тянется в Винде до сих пор.
Естественно, графические приложения, работавшие с GDI, были гораздом медленнее работавших с виеопамятью напрямую: ведь на каждый вызов GetPixel/SetPixel приходились сотни системных вызовов. Поэтому начиная с Win30, в GDI появилась поддержка DIB: блоков памяти, с которыми можно работать напрямую побайтно, причём соответствующие изменения отображались в том DC, куда был выбран DIB. Несмотря на удобство работы с DIB, многие программисты почему-то по-прежнему работают с GetPixel/SetPixel.
И в завершение экскурса в историю, о BitBlt. Согласно официальной трактовке, это читается "БитБлит" и означает Bit Block Transfer. В старых Виндах, которые могли работать с цветностью 4bpp или менее, для переноса куска изображения из одного DC в другое было недостаточно переноса байт; нужно было "рассекать" байты по границе области переноса и "вклеивать" их посреди байтов приёмника. Это было достаточно нетривиально и, действительно, требовало специальной функции. Сейчас же, когда цветность у всех 8bpp и более, BitBlt по сути осуществляет Byte Block Transfer - а это уже можно выполнить обычным двойным циклом. Мораль: не юзайте GetPixel, SetPixel и BitBlt, работайте сразу с данными картинки.
Как ещё один памятник истории, сохранены флаги класса окна CS_BYTEALIGNCLIENT и CS_BYTEALIGNWINDOW, которые использовались для ускорения отрисовки в окно и позволяли ему занимать только целое число байт в видеопамяти (т.е. не позволяли какому-нибудь байту видеопамяти быть наполовину в окне и наполовину вне его). Сейчас, при цветности 8bpp и более, эти флаги эффекта уже не имеют.
Вот, почти статья получилась. Стандартный дизклеймер: ни за что, написанное в ней, я не отвечаю; при воспроизведении сохранение копирайта обязательно.

[Approximator]

Не из вредности.

Ещё, мне кажется, стоит рассказать про то, зачем вообще нужны DC.

Хочется - расскажи. Кста, imo, в твоём последующем тексте "про это" почти ничего не было сказано.

И в завершение экскурса в историю, о BitBlt. Согласно официальной трактовке, это читается "БитБлит" и означает Bit Block Transfer. В старых Виндах, которые могли работать с цветностью 4bpp или менее, для переноса куска изображения из одного DC в другое было недостаточно переноса байт; нужно было "рассекать" байты по границе области переноса и "вклеивать" их посреди байтов приёмника. Это было достаточно нетривиально и, действительно, требовало специальной функции. Сейчас же, когда цветность у всех 8bpp и более, BitBlt по сути осуществляет Byte Block Transfer - а это уже можно выполнить обычным двойным циклом. Мораль: не юзайте GetPixel, SetPixel и BitBlt, работайте сразу с данными картинки.

Мораль нормальная, но лишь в отношении Get/SetPixel. Ибо, Bit Blitting происходит несравненно быстрее нежели Get/SetDIBits. И это объяснимо - ведь по сути приходится сначала битовый образ форматировать, а уже затем запихивать его по месту Device контекстной памяти. Я уже не говорю про то, что может понадобиться в цикле эти байты обрабатывать... Мораль, прежде чем советовать - тестируй на производительность, то бишь не используй истины: "не верь глазам своим - поверь своей совести".

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

Вон, оказывается, как тебя сильно на этом клинит. Не сердись, nothing personal.

[arechemist]

всмысле Эюзайте сразу данные картинки..."?
Но перед тем как их юзать их вроде бы сначала нужно достать из файла и переписать куда-нибудь пикчурбокс например... как я делал раньше, но тут я узнал про DC, которые занюмают меньше памяти чем пикчур боксы и хочу узнать как с ними можно работь...

А не мог бы кто-нибудь написать маленький примерчик работы с DC
Ну там созданию, засовывание в нее какую-нибудь картинку и удаление чтоб было в это примерчике... Я буду очень благодарен...

[tyomitch]

Ещё, мне кажется, стоит рассказать про то, зачем вообще нужны DC.

Хочется - расскажи. Кста, imo, в твоём последующем тексте "про это" почти ничего не было сказано.

Ну как же ничего:

Под это дело была разработана концепция DC: программист не знает, какова структура под-лежащего устройства, какая там глубина цвета, какое выравнивание строк и т.п. Он просто пишет код, оперируя понятиями "кистей" и "перьев", а ОС сама преобразует их в операции над соответствующим устройством.

Мораль нормальная, но лишь в отношении Get/SetPixel. Ибо, Bit Blitting происходит несравненно быстрее нежели Get/SetDIBits. И это объяснимо - ведь по сути приходится сначала битовый образ форматировать, а уже затем запихивать его по месту Device контекстной памяти. Я уже не говорю про то, что может понадобиться в цикле эти байты обрабатывать... Мораль, прежде чем советовать - тестируй на производительность, то бишь не используй истины: "не верь глазам своим - поверь своей совести".

Get/SetDIBits здесь вообще не при чём. Я о создании битмапа из двумерного массива и работы с ним попиксельно как с двумерным массивом. Скорость этого трюка я проверял - мне понравилось.
Ещё раз, не о создании буфера битмапа в двумерном массиве, а о создании самого битмапа.

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

Вон, оказывается, как тебя сильно на этом клинит. Не сердись, nothing personal.

"У каждого придурка свои радости" (с)

[Approximator]

Ещё, мне кажется, стоит рассказать про то, зачем вообще нужны DC.

Хочется - расскажи. Кста, imo, в твоём последующем тексте "про это" почти ничего не было сказано.

Ну как же ничего:...

Я сказал почти ничего. На самом деле GDI это универсальный интерфейс и способен работать не только с монитором , при этом, работая через него вовсе не обязательно задумываться как об особенностях hardware, так и об особенностях поставляемых драйверов... Впрочем, про DC не у меня было желание рассказывать, а у тебя вот и отдувайся. "Назвался груздём..."

Мораль нормальная, но лишь в отношении Get/SetPixel. Ибо, Bit Blitting происходит несравненно быстрее нежели Get/SetDIBits. И это объяснимо - ведь по сути приходится сначала битовый образ форматировать, а уже затем запихивать его по месту Device контекстной памяти. Я уже не говорю про то, что может понадобиться в цикле эти байты обрабатывать... Мораль, прежде чем советовать - тестируй на производительность, то бишь не используй истины: "не верь глазам своим - поверь своей совести".

Get/SetDIBits здесь вообще не при чём. Я о создании битмапа из двумерного массива и работы с ним попиксельно как с двумерным массивом. Скорость этого трюка я проверял - мне понравилось.
Ещё раз, не о создании буфера битмапа в двумерном массиве, а о создании самого битмапа.

Если об ОДНОКРАНОМ заполнении битмапа - нет вопросов, если же... кста, что за "попиксельная работа", то есть, что именно необходимо было сделать с ОТДЕЛЬНЫМ пикселем (например)? Конечно, может быть сама задача не позволяла использовать стандартные процедуры (логические операции над массивом данных с использованием, пускай даже обсчитываемых, примитивов), но, что-то мне подсказывает, что ты просто на корню отверг подобную возможность (ну, не любят некоторые люди математику, что ж с того?). Разубеди.

[tyomitch]

Ещё, мне кажется, стоит рассказать про то, зачем вообще нужны DC.

Хочется - расскажи. Кста, imo, в твоём последующем тексте "про это" почти ничего не было сказано.

Ну как же ничего:...

Я сказал почти ничего. На самом деле GDI это универсальный интерфейс и способен работать не только с монитором , при этом, работая через него вовсе не обязательно задумываться как об особенностях hardware, так и об особенностях поставляемых драйверов... Впрочем, про DC не у меня было желание рассказывать, а у тебя вот и отдувайся. "Назвался груздём..."

Я не говорил про монитор, я говорил про "под-лежащее устройство".
Про независимость от hardware и конкретных драйверов я писал в самом первом абзаце.
Короче, всё, что я хотел сказать - я сказал. Если кто-то чего-то не понял, или не нашёл в тексте - его проблемы. Я считаю, что зачем вообще нужны DC я рассказал достаточно полно и подробно.

Если об ОДНОКРАНОМ заполнении битмапа - нет вопросов, если же... кста, что за "попиксельная работа", то есть, что именно необходимо было сделать с ОТДЕЛЬНЫМ пикселем (например)? Конечно, может быть сама задача не позволяла использовать стандартные процедуры (логические операции над массивом данных с использованием, пускай даже обсчитываемых, примитивов), но, что-то мне подсказывает, что ты просто на корню отверг подобную возможность (ну, не любят некоторые люди математику, что ж с того?). Разубеди.

Короче, я ниччё не понял. Объясни, можешь личкой, что тебе надо - начну разубеждать.

[GSerg]

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

[tyomitch]

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

Так не бывает.
Т.е. это возможно, но так не бывает.
Если только область применения не какая-то узкоспецифичная (напр. комп с полуметровой видеокартой)

Я про то, что не стоит к функциям привыкать, а не про то, что они вообще лишние и никогда не нужны.

[Approximator]

Ещё, мне кажется, стоит рассказать про то, зачем вообще нужны DC.

Хочется - расскажи. Кста, imo, в твоём последующем тексте "про это" почти ничего не было сказано.

Ну как же ничего:...

Я сказал почти ничего. На самом деле GDI это универсальный интерфейс и способен работать не только с монитором , при этом, работая через него вовсе не обязательно задумываться как об особенностях hardware, так и об особенностях поставляемых драйверов... Впрочем, про DC не у меня было желание рассказывать, а у тебя вот и отдувайся. "Назвался груздём..."

Я не говорил про монитор, я говорил про "под-лежащее устройство".
Про независимость от hardware и конкретных драйверов я писал в самом первом абзаце.
Короче, всё, что я хотел сказать - я сказал. Если кто-то чего-то не понял, или не нашёл в тексте - его проблемы. Я считаю, что зачем вообще нужны DC я рассказал достаточно полно и подробно.

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

Если об ОДНОКРАНОМ заполнении битмапа - нет вопросов, если же... кста, что за "попиксельная работа", то есть, что именно необходимо было сделать с ОТДЕЛЬНЫМ пикселем (например)? Конечно, может быть сама задача не позволяла использовать стандартные процедуры (логические операции над массивом данных с использованием, пускай даже обсчитываемых, примитивов), но, что-то мне подсказывает, что ты просто на корню отверг подобную возможность (ну, не любят некоторые люди математику, что ж с того?). Разубеди.

Короче, я ниччё не понял. Объясни, можешь личкой, что тебе надо...

Мне - ничего. Думал, что может пригодиться тебе. Если нет - ещё раз прости, видимо то, что я написал прошло "мимо бани". Не забивай голову.

[Approximator]

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

Не, я не об этом. А о том, что функции выполняющие прямой логический блиттинг (которые Тёмычу не нравятся) работают несравненно быстрее, чем работа побайтно. А ими ЛЮБУЮ работу побайтно с картинкой можно заменить. Но тут, я же сказал, необходимо желание того, кто это делает, а если его нет - навязываться не буду.

[GSerg]

Хм... Да. Видимо, не зря есть фича девайса RC_BITBLT