> а на счет VC, не нравится он мне, интерфейс какой то не > очень дружественный :) Вон у vim-а вообще интерфеса нет, а люди которые знают в нем что либо, кроме :q! (я знаю: Shift - ZZ - в смысле подряд два Z с шифтом :-))) ) - ставят его в один ряд с IDE от билдеров и прочих визуал сей. Некоторые говорят, что на билдере легче интерфейсы создавать, а я так даже MFC не люблю - только plain С и DlgProc (к которому все-таки и сводятся все билдеровские извраты). Да, так отчасти сложнее в простых ситуациях, но в виду полного контроля над ситуацией гораздо безболезненней разруливаются ситации сложные (именно за это я люблю C)
Мои претензии к билдеру:
1) Уж очень тормознутый, как при компиляции, так и, например, в отображении (ну не помню как это в нем называется) прототипов функций, типов переменных и т.д. при наведении мыши, автодополнении членов класса и т.д.
2) Много извращений: в частности property - действительно можно было реализовать простой перегрузкой оператора = и конструкторов.
3) Сильно большой и почти всегда более тормознутый код.
4) Если уж де-факто (ну не написали в борланде своей ОС-и со своим GDI) есть например структура, представляющая ресурсы (в частности диалог) внутри самой ОС-и, то какого хранить эти ресурсы в текстовом виде, потом динамически строить эту структуру и отдавать ее системе. Особенно мне не нравится, то что синтаксис этого псевдоязыка для описания ресурсов явно паскалеподобный - ну не нравится он мне. Извините, если кого обижу, но на паскале имхо пишут те, кому лень или не по силам выучить цэ.
Не нравится потому, что это говорит о разработчиках борлянда.
5) Много граблей, непонятно откуда возникающих и отнимающих много времени. В частности один мой знакомый почти неделю искал багу в своей проге, и в конце концов нашел багу в стандартной библиотеке (это было давно и не с билдером, а с BCC 5.02).
А вот совсем недавний случай: была структурка:
if (ядреное_условие)
continue;
---
Этот самый continue выполнялся ВСЕГДА.
После того, как пару часов промучались меняя условие, вводя промежуточные переменные и отслеживая их в дебаггере, и в конце концов сведя код к:
if (false)
continue;
---
Просто для того, чтоб проверить кто из нас глючит; оказалось, что он - в этой конструкции всегда выполнялось continue. Двадцать раз перепроверяли, нет ли там лишней точки с запятой, удаляли полностью эти строки и перенабирали полностью. В общем-то понятно, что если бы так происходило всегда, вне зависимости от контекста, бага не дожила бы до 6-й версии, поэтому мы начали менять контекст. Сначала заменили continue на {continue;} - не помогло. Помогло следующее:
if (то_же_самое_ядреное_условие_взятое_из_CVS_а) {
int a = 3;
continue;
}
Елки-палки, но на это же ушло несколько часов. Нет, я предпочитаю знать, что происходит
ЗЫ: отписать баг репорт не смогли, так как не смогли написать тестовое повторение баги, а отсылать весь проект не хотелось - коммерческий все-таки.
но, много картинок, в окне слишком накладно для памяти, те более я проверял, такие виеверы как ACDSee, практически не исспользуют оперативную памяти при выводе изображений на экран, и как это у них получается....
Дык ACDSee не билдере писан :-)))16.01.03 16:15 Автор: amirul <Serge> Статус: The Elderman
> но, много картинок, в окне слишком накладно для памяти, те > более я проверял, такие виеверы как ACDSee, практически не > исспользуют оперативную памяти при выводе изображений на > экран, и как это у них получается....
Точно не на билдере - можешь ресурсы (в частности диалоги) глянуть как генерит VC и как BCB
ЗЫ: Хотя мне больше нравятся XnView или SlowView - последние версии ACDSee уж больно монстрообразны и тормознуты, а в предпоследних фич поменее.
> Точно не на билдере - можешь ресурсы (в частности диалоги) > глянуть как генерит VC и как BCB > > ЗЫ: Хотя мне больше нравятся XnView или SlowView - > последние версии ACDSee уж больно монстрообразны и > тормознуты, а в предпоследних фич поменее. Меня честно говоря тоже непривлекает последняя версия, поэтому пользуюсь 3-ей, привык уже,
а на счет VC, не нравится он мне, интерфейс какой то не очень дружественный :)
Это все от опыта зависит16.01.03 22:11 Автор: amirul <Serge> Статус: The Elderman
> а на счет VC, не нравится он мне, интерфейс какой то не > очень дружественный :) Вон у vim-а вообще интерфеса нет, а люди которые знают в нем что либо, кроме :q! (я знаю: Shift - ZZ - в смысле подряд два Z с шифтом :-))) ) - ставят его в один ряд с IDE от билдеров и прочих визуал сей. Некоторые говорят, что на билдере легче интерфейсы создавать, а я так даже MFC не люблю - только plain С и DlgProc (к которому все-таки и сводятся все билдеровские извраты). Да, так отчасти сложнее в простых ситуациях, но в виду полного контроля над ситуацией гораздо безболезненней разруливаются ситации сложные (именно за это я люблю C)
Мои претензии к билдеру:
1) Уж очень тормознутый, как при компиляции, так и, например, в отображении (ну не помню как это в нем называется) прототипов функций, типов переменных и т.д. при наведении мыши, автодополнении членов класса и т.д.
2) Много извращений: в частности property - действительно можно было реализовать простой перегрузкой оператора = и конструкторов.
3) Сильно большой и почти всегда более тормознутый код.
4) Если уж де-факто (ну не написали в борланде своей ОС-и со своим GDI) есть например структура, представляющая ресурсы (в частности диалог) внутри самой ОС-и, то какого хранить эти ресурсы в текстовом виде, потом динамически строить эту структуру и отдавать ее системе. Особенно мне не нравится, то что синтаксис этого псевдоязыка для описания ресурсов явно паскалеподобный - ну не нравится он мне. Извините, если кого обижу, но на паскале имхо пишут те, кому лень или не по силам выучить цэ.
Не нравится потому, что это говорит о разработчиках борлянда.
5) Много граблей, непонятно откуда возникающих и отнимающих много времени. В частности один мой знакомый почти неделю искал багу в своей проге, и в конце концов нашел багу в стандартной библиотеке (это было давно и не с билдером, а с BCC 5.02).
А вот совсем недавний случай: была структурка:
if (ядреное_условие)
continue;
---
Этот самый continue выполнялся ВСЕГДА.
После того, как пару часов промучались меняя условие, вводя промежуточные переменные и отслеживая их в дебаггере, и в конце концов сведя код к:
if (false)
continue;
---
Просто для того, чтоб проверить кто из нас глючит; оказалось, что он - в этой конструкции всегда выполнялось continue. Двадцать раз перепроверяли, нет ли там лишней точки с запятой, удаляли полностью эти строки и перенабирали полностью. В общем-то понятно, что если бы так происходило всегда, вне зависимости от контекста, бага не дожила бы до 6-й версии, поэтому мы начали менять контекст. Сначала заменили continue на {continue;} - не помогло. Помогло следующее:
if (то_же_самое_ядреное_условие_взятое_из_CVS_а) {
int a = 3;
continue;
}
Елки-палки, но на это же ушло несколько часов. Нет, я предпочитаю знать, что происходит
ЗЫ: отписать баг репорт не смогли, так как не смогли написать тестовое повторение баги, а отсылать весь проект не хотелось - коммерческий все-таки.
Да, согласен, билдер особенно 6 раздражает своей "интелектуальностью", пытаясь за тебя "додумать" окончание названия функций, компилид долго, и все такое, да и вообше Борландовские компиляторы часто глючат, но в них мне нравится одна особенность, удобно исправлять синтаксические ошибки, так как редектор автоматически устанавливает курсор на ошибку.
А в VC редактор только указывает номер строки, при этом индексация строк кода не производится (это немного раздражает), это мое субективное мнение, может просто потому что я мало работал с VC.
Наверное именно поэтому17.01.03 13:01 Автор: amirul <Serge> Статус: The Elderman
> Да, согласен, билдер особенно 6 раздражает своей > "интелектуальностью", пытаясь за тебя "додумать" окончание > названия функций, компилид долго, и все такое, да и вообше > Борландовские компиляторы часто глючат, но в них мне > нравится одна особенность, удобно исправлять синтаксические > ошибки, так как редектор автоматически устанавливает курсор > на ошибку.
Это одно из проявлений интеллектуальности борлянда. Он иногда делает, то чего мне не надо без спросу. Не обязательно сразу после компиляции я захочу кинуться к месту возникновения ошибки. Например, если я нахожусь в начале блока/функции и при компиляции узнаю, что некоторая переменная не объявлена, а меня кидает к первому ее использованию. Но это не совсем то, чего я хочу, хотя борланду так кажется.
> А в VC редактор только указывает номер строки, при этом
В VC чтобы перейти к какой либо конкретной ошибке нужно или кликнуть по ошибке в окне вывода, или нажать F4 (следующая ошибка) Shift-F4 (предыдущая). Есть еще несколько способов. А когда я начал просматривать все команды (из Customize->Keyboard), в том числе и те, которым просто не хватило клавиш - я прозрел. Какую бы неприязнь я не испытывал к Microsoft-у, VC это единственный их продукт, который мне нравится. Более того, это самый удобный IDE, с которым я работал. Сразу скажу, что работал я со многими (и не только под виндой и не только на PC), причем начинал именно с борландовского C 3.1, после которого недолго думая пересел на 5-й, в том числе и из-за предвзятого отношения к Microsoft. Но позже я все-таки решил попробовать VC, о чем не жалею: у нас-то что BC, что VC стоят 2 бакса за компакт.
> индексация строк кода не производится (это немного > раздражает), это мое субективное мнение, может просто > потому что я мало работал с VC.
> Ну что ж, наверное все таки поставлю еще раз VC и > хорошенько пошарю по все настройкам.... А на VC как с > картинками работать
Вообще все API в твоем распоряжении - MSDN под руки и в путь. Вот первый попавшийся пример оттуда (MFC мать его :-))) )
CMyWnd::OnRButtonDown(int nFlags, CPoint mouse)
{
CMenu menu;
CImage image;
// Code to create menu and load/create image goes here
CBitmap* pBitmap = CBitmap::FromHandle(image.m_hBitmap);
menu.AppendMenu(0, ID_SOMECOMMAND, pBitmap)
menu.TrackPopupMenu(TPM_RIGHTBUTTON | TPM_LEFTALIGN, mouse.x, mouse.y, this);
}
---
Если разобраться, то борляндовские компоненты и мелкософтовские интерфесы суть одно и то же. С той лишь разницей, что ребята из M$ лучше знают свою ось и лучше финансируются.
Ненамного сложнее, чем у борланда, но я бы наверное сам ковырялся в чем-нить типа DirectDraw - для повышения эффективности и полного контроля за ситуевиной.
Еще на твоем месте я бы поискал на sourceforge "Developer's Image Library" - DevIL. Она идет не только на VC - портабельность вроде даже не только под вынь (точно не уверен, но кажется так и есть), не то что VC - BCB. А набор фич и поддерживаемых форматов меня мягко говоря впечатлил. Распространяется под LGPL. А вообще надо почаще на sourceforge заглядывать (это и себе тоже пожелание) - там ну очень много интересного. Или в этом случае тоже не приемлим чужой код?
Итак, винда прислала твоей многостродальной софтине сообщение WM_PAINT. Это значит, что винда определила, что некий кусок окна в твоём приложении нуждается в прорисовке. Это может произойти, к примеру, когда часть окна была закрыта окном другого приложения, а тут мы его свернули... Итак, надо прорисовывать... Что обычно делаем в Builder'e с классами VCL (TImage который) ? Правильно, в конце концов вызывается метод TCanvas->Draw, который отрисует некий TGraphic. А на нижнем уровне, на уровне функций Windows GDI отрисовывается в конце концов Bitmap или Metafile, который обязательно должен быть где-то в оперативной памяти.
Теперь далее. Скорей всего это Bitmap... или DIB... ACDSEE читает граф. файл, оптимизирует его для экранного разрешения и хранит в памяти. Предположим, он может хранить в памяти одновременно не более трёх. При разрешении 1024х768 размер 32-битного изображения будет 1024*768*4(байта) будет 3145728 байт. Итого 9 мегабайт. Много это или мало для современных компьютеров — это ещё тот вопрос.
Что за изображения ты грузишь в TImage? Если они высокого разрешения, то могут сильно напрягать твоё приложение и систему в целом. Загружаемое изображение надо оптимизировать под экранное разрешение.
Надо заметить, что классы VCL для работы с изображениями не предназначены для профессионального использования. Да и ты тоже нашёл с чем сравнить — с ACDSee, эту софтину ребята вылизывают много лет и имеют неплохие бабки с неё. Работают они с OS на низком уровне.
Читай документацию по функциям Windows GDI, DIB и проч.
Ну, оптимизировать картинку под размер окна мне не нужно, так как работаю с пикселами на уровне битов, поэтому картинка нужна полностью в оперативной памяти, но желателино чтобы она содержалась не в TImage, а в динамическом массиве, так как обращение к байтам картинки помещенной вTImage в цикле, немного усложнено (приходится пересчитывать координаты пкселей из двухмерных в одномерные, а это значительно замедляет весь процесс), а хранить два изображения (одно в TImage, одно в массиве) накладно, может посоветуеш как отображать и регенерировать картинку не исспользуя TImage?
А на счет ACDSee я все понимаю, просто была интересна технология.
Если делать битмэп то винда его запросто может в видеопамять засунуть- типа 2D ускорение17.01.03 01:48 Автор: Killer{R} <Dmitry> Статус: Elderman
Правда, а как это сделать, и как потом оз памати карты этот битмап извлечь, мне ж потом преобразованый битмап сохранить нужно, тем более преобразовать его нужно всего один раз, в чем тогда будет состоять ускорение?
это интересно17.01.03 11:43 Автор: Killer{R} <Dmitry> Статус: Elderman
пробразовывать ты его будешь путем копирований в другие hdc (BitBlt - функция аппаратно поддерживаемая практически всеми более-менее современными видеокартами), растяжения/сжатия(StretchBlt), повороты PlgBlt - все это делается на уровне АПИ не с самими адресами памяти а HBITMAP. Если нужны конкретные цвета пикселей - делается GetDIBits. А откуда берутся пиксели - вопрос только винды и драйверов видюхи.
это интересно17.01.03 17:24 Автор: zim Статус: Незарегистрированный пользователь
но мне не нужны не повороты не растяжения, мне необходимо преобразовать только младхие биты цветов пикселей, а потом преобразованую картинку сохранить, вот и все.
как преобразовать?17.01.03 23:20 Автор: Killer{R} <Dmitry> Статус: Elderman
Между прочим в том же BitBlt есть куча методов рисования картинки - и XOR, и OR, и AND и помудренее... А вообще если хочешь на API делаешь битмэп. И если очень хочешь оптимизировать память - вытаскиваешь из него в буфер строки GetDIBits делаешь с ними в памяти что хошь а потом засовываешь в битмэп - SetDIBits
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
