мне нужно максимально быстро заполнять dc. Да и потом СОМ этот.....| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Системное программирование и WinAPI > SetDIBits не срабатывает |
| Автор: deniska 31.8.2006, 10:23 |
| Функции SetDIBits, SetBitmapBits, SetDIBitsToDevice не срабатывают при увеличении размера рисунка. Может сработат, а может и нет, причем вернет 0 и она и GetLastError. Почему такая нестабильность? Кто-нибудь с таким сталкивался? |
| Автор: Earnest 31.8.2006, 10:36 |
| Что значит - не срабатывает? |
| Автор: deniska 31.8.2006, 10:55 |
| Это значит что возвращает 0 |
| Автор: GremlinProg 31.8.2006, 12:30 |
| да, бывало такое, что SetDIBitsToDevice иногда не заполняло девайс. Выбрал альтернативу - рендеринг IPicture. |
| Автор: deniska 31.8.2006, 12:36 |
| не пойдеть мне нужно максимально быстро заполнять dc. Да и потом СОМ этот..... |
| Автор: GremlinProg 31.8.2006, 12:45 |
| так что лучше, скорость или надежность? На некоторых виндовозах SetDIBitsToDevice вообще отказывался работать, возможно тут аппаратная зависимость: мне приходилось рендерить на довольно ёмкие девайсы |
| Автор: deniska 31.8.2006, 13:06 |
| Нет, ну должно же быть какое-то нормальное объяснение почему несрабатывает. Честно говоря первый раз столкнулся с фигней. Всегда думал что на АПИ писать надежнее Добавлено @ 13:08 В конце концов IPicture в итоге теми же ф-циями пользуется. Наверно..... |
| Автор: GremlinProg 31.8.2006, 14:40 |
| IPicture, канешн теми же, видимо есть где-то проблема, которую IPicture обходит, потому что я досканально все проверил, уповал на адрес(его варавнивание), дак нет, не в нем дело, все параметры просчитывал, в принципе использую RGBQUAD, поэтому проблем с выравниванием каждой строки на границе слова у мя не было, но это тоже необходимо учитывать, проверь это дело у себя. |
| Автор: Earnest 31.8.2006, 16:21 |
| А вместо них нельзя использовать BitBlt со товарищи? Никогда не встречалась с их "не-срабатываниями". Да, несколько другие исходные данные: 2 контекста, а не растр + контекст, но это вообще не проблема. В чем специфика задачи, что нужно именно SetDIBits? Блиттинг работает не медленнее... Кстати, функции IPicture. скорее всего, как раз на блиттингах реализованы. |
| Автор: GremlinProg 31.8.2006, 18:28 |
| Earnest, а доступ к растру прикажешь GetPixel'ом организовывать? )) Очевидно же, что необходим прямой доступ. Добавлено @ 18:33 IPicture организует диб-образ в вирт. памяти(это можно проверить GetObject'ом), следовательно дамп образа мэпируется в граф. девайс напрямую, а SetDIBits, по крайней мере, это делает. Вывод: IPicture скорее всего опирается на SetDIBits и ей подобные. |
| Автор: Earnest 1.9.2006, 06:50 |
| А кто против? Заведи DIB-секцию, и будет и прямой доступ, и возможность выбора в контекст. DIB-растр в DIB-секцию элементарно превращается. Добавлено @ 06:52 Кстати, работа с контекстами (и DIB-секцией) хороша еще тем, что автоматически получаешь возможность растризовать любые векторные примитивы - GDI рисует... |
| Автор: GremlinProg 1.9.2006, 08:15 |
| Earnest, а в чем, собственно, проблема? Я вроде как о DIB-секции и говорю. В этом и преимущество IPicture. Только секция создается сразу, без лишних вопросов. Это экономит кучу времени. |
| Автор: Earnest 1.9.2006, 09:38 |
| IPicture, как бы оно не реализовывалась, это обертка вокруг API, т.е. есть какие-никакие лишние издержки. Я не знаю, почему автор не хочет IPicture. Может, GDI+ не хочет подключать. Поэтому и предлагаю АПИшную альтернативу функциям SetDIBits и пр., которая всегда работает - я, по крайней мере, не сталкивалась с косяками блиттинга. Хотя не исключено, что у него просто косяки в коде. |
| Автор: GremlinProg 1.9.2006, 09:51 |
| GDI+ тут совершенно ни при чем (может путаешь с оберткой CPicture). Ему просто не хочется связываться с OLE, как он уже успел заметить (хотя, на мой взгляд, это не должно быть так обременительно, как например тот же GDI+, которому нужна таки библиотека. OLE поддерживается везде и уже давно) Добавлено @ 10:03 Альтернатива, конечно, всегда есть. Можно использовать и CreateDIBSection, но, если необходимо загрузить в эту секцию растр из файла любого из зарегистрированных в системе граф. типов (jpeg, bmp, tif...), то я все же порекомендовал бы IPicture. |
| Автор: Earnest 1.9.2006, 10:52 |
| Да, пожалуй, спутала... Не... OLE никому не порекомендую - уж там-то издержки... Лучше тогда CImage использовать (GDI+ ИМХО, лучше чем OLE). А класс простой. |
| Автор: deniska 1.9.2006, 11:01 | ||
 Может, может. Сейчас вот сижу капаюсь. BitBlt я пробовал. С него собственно и начал. Функции возвращают 0 при увеличении картинки где-то с 500*500 У меня в окне есть область которая заполняется фоном с градиентом. Эту область я мышой могу ресайзить. Пока размер области небольшой, все вроде работает |
| Автор: GremlinProg 1.9.2006, 11:40 | ||||
Конечно, не все OLE-компоненты универсальны и удобны, но не нужно судить так обо всех интерфейсах , я тоже сталкивался с некоторыми излишествами в OLE, но мы сейчас говорим конкретно об одном:
Здесь get_Handle возвращает HBITMAP, с которым можно работать как обычно, а метод Render делает очень полезную вещь: рендерит в указанный девайс любой кусок HBITMAP, с нужным масштабом, причем метод рендеринга выбирается тот, который поддерживается системой: если это битмап, то происходит нечто похожее на StretchDIBits, если упакованный жипех, то его собственный рендеринг. Т.е. Render избавляет нас от лишней мороки, да и о качестве говорить не приходится. Остальные методы, роли не играют, они просто дублируют соответствующие вызовы API, так что нагрузки особой на ресурсы не несут. |
| Автор: Earnest 1.9.2006, 12:10 | ||
Так может у тебя с преобразованием координат какая-то ерунда? Там же есть ограничения... Или еще что-то в этом роде... Покажи кусок кода. Добавлено @ 12:12 Я думаю, что в этом случае ни IPicture, ни CImage тебя не спасут... нужно разобраться с координатами |
| Автор: deniska 1.9.2006, 12:51 | ||
Я думаю не должно так как при небольших то размерах работает нормально а координаты считаются одинаково для любого размера. Мне этими функциями приходилось пользоваться так как градиент я ручками делал (массив заполнял). потом этот массив надо было в dc записывать. Сейчас попробовал FillGradient. Сижу и наслаждаюсь: в 3 раза быстрее, никаких глюков с прорисовкой, про память под массив париться не нужно. В общем пока одни достоинства. Спасибо Earnest и GremlinProg что пытались помочь P.S. Все равно странно почему же глюковало? Надо руки выпрямлять наверно.... |
| Автор: Earnest 1.9.2006, 12:59 | ||
Существуют ограничения |
| Автор: GremlinProg 1.9.2006, 14:18 | ||||
однако же IPicture как раз и спасло, я уже говорил )
Лучше всего сразу о таких вещах сообщать, т.е. говорить не так, мол не работает функция, а сразу пояснять задачу и цели, тогда тебя будет проще понять. Действительно, специализированные функции, такие как AlphaBlend, BitBlt, StretchBlt, FillGradient и т.п. как правило работают намного быстрее, нежели их пытаться реализовать, пусть даже через прямой доступ. Прямой доступ к растру лучше использовать только когда необходимо применить к нему какой-то собственный алгоритм, который не имеет аналогов в API, либо когда нужен попиксельный анализ растра. |
