Цитата или краткий комментарий:

• Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
• Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
  
• При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
• Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.

Отслеживать это обсуждение

сообщение от автора материала Думается, что приложение сразу берёт большой кусок памяти у системы, а потом в этом большом куске резервируются участки через new/getMem/realloc. Да, это действительно так. Но это не отменяет того, что я сказал - что память не сразу возвращается системе. Там есть ещё вроде как различия в зависимости от размеров создаваемых переменных. Для "мелких" используется участок памяти, который системе вообще не возвращается, пока программа не завершится. Хотя я уже не помню, давно разбирался, и только с "семёркой". Как раз в семёрке никаких зависимостей от размера нет, они есть в FastMM, который стал стандартным только в более новых версиях Delphi. Так вот я всё это к чему. VCL сама написана "некорректно". То есть она работает с уже удалёнными переменными. Убедиться в этом по-быстрому можно скачав отсюда http://janych.selfip.com/Examples/Delphi/MemoryLeak/ (внизу) мой UdebugMemoryLeak.pas (указать первым в uses dpr-файла) и включив forceViolations:=true; Ссылка, к сожалению, битая, посмореть ваш пример не могу, но о том, что VCL работает с уже удалёнными переменными, я сам тоже писал: http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1153 Правда, я, видимо, рассмотрел не ту ситуацию, о которой пишете вы.  Антон Григорьев

сообщение от автора материала Недавно первый раз прочитал статью, я начинающий, скачал примеры. В примере ButtonDel код, убивающий кнопку "в лоб", работоспособен. Кто-нибудь может объяснить? Это связано с особенностями работы менеджера памяти Delphi. Он нередко придерживает освобождённую память, не возвращая её сразу системе, чтобы потом иметь возможность быстрее выделить её снова, когда она ещё для чего-то понадобится. Чтобы не снижать производительность, освобождённая память не очищается. В данном случае это означает, что в освобождённой памяти продолжают лежать данные, составляющие уже удалённый объект Button1, поэтому код VCL, обращающийся к этим данным, не замечает удаления и продолжает работать. Но то, вернёт ли менеджер памяти системе освобождённую память или нет, зависит от предыстории выделения и освобождения памяти, которая в большой сложной программе плохо предсказуема. Там вполне можно получить Access violation. Вообще, то, что менеджер памяти не возвращает освобождённую память немедленно, служит причиной многих подобных ситуаций, когда некорректно написанный код вроде как работает и не выдаёт никаких ошибок.  Антон Григорьев

>>> <...> или это ваша обычная манера общения? Если это тот же Борис Телеснин, что и пользовательс с ID=4922, то, скорее всего, это действительно такая манера общения :(  Geo

сообщение от автора материала Борису Телеснину: если бы задача состояла в этом, то вролне хватило бы и SetWindowLong на одну процедуру для всех экземпляров класса. И вообще не было бы нужды в "самомодификации кода", просто по ващей логике преобразование "HW(хэндл окна) ->указатель на объект" вы бы спокойно сделали в процедуре общей для всего класса каким нибудь поиском в массиве. Почему SetWindowLong не подходит, я объяснил в статье: первые несколько сообщений окно получает ещё до завершения работы CreateWindow(Ex), т.е. до того, как может быть вызвана SetWindowLong. А насчёт массива - вы ходь представляете, сколько сообщений получает окно? И сколько процессорного времени было бы потрачено впустую, если каждый раз при обработке искать окно? Лично я не могу предложить ни одного более универсального варианта обработки сообщений с сохранением эффективности, чем тот, который реализован в VCL. Может быть, вы можете? из чего я делаю вывод что дельфю писали не вы Предыдущее своё сообщение вы начали со слова "бред", здесь какие-то подколки насчёт авторства VCL, на которое я никогда не претендовал, в сообщение с извинениями вы вставили замечание о том, что заставили меня лишний раз программировать, которое "по форме правильное, по сути издевательство" (не знаю ваш возраст, поэтому на всякий случай поясню, что это цитата из Ленина). Это лично я вам чем-то досадил, что вы себе такое позволяете, или это ваша обычная манера общения?  Антон Григорьев

сообщение от автора материала Борис Телесин: Прежде чем называть бредом то, что я написал, объясните, что означает фраза "The function dispatches incoming sent messages until a posted message is available for retrieval" в описнии функции GetMessage. Минимальный цикл обработки сообщений обязан включить вызов DispatchMessage( кроме GetMessage) Абсолютно точно. Можете ещё раз прочитать статью и убедиться, что так я и написал. Без DispatchMessage не смогут обрабатываться сообщения, посланные с помощью PostMessage, а обрабатывать их необходимо. Проверить это проще пареной репы- вызвать sendMessage,  из другого потока. При этом поставить точку останова в обработчике сообщения формы и сразу после вызова GetMessage Специально поставил такой эксперимент. Нить такая: unit Unit2; interface uses   Windows, Messages,Classes; const WM_TEST = WM_USER + 1; type   TTestThread = class(TThread)   private     { Private declarations }   protected     procedure Execute; override;   end; implementation uses Unit1; { TTestThread } procedure TTestThread.Execute; begin   repeat    SendMessage(Form1.Handle, WM_TEST,0,0);    Sleep(500)   until False end; end. Обработчик сообщения такой: procedure TForm1.WMTest(var Msg:TMessage); begin   Label1.Caption:=IntToStr(Random(1000)) end; Точку останова поставил в TPallication.ProcessMessage на вызове DispathMessage (чтобы это стало возможно, включил опцию Use Debug DCUs). Условие на точку останова наложил Msg.Message = WM_USER + 1. Останов не происходил, хотя текст Label1 менялся. Для чистоты эксперимента заменил SendMessage на PostMessage, и точка останова начала срабатывать. Вы этот эксперимент имели ввиду? Так он ваши же слова и опровергает. Так что я жду от вас либо дальнейших разъяснений, либо извинений за слово "бред".  Антон Григорьев

сообщение от автора материала Просьба прояснить что же такого делают GetMessage\PeekMessage что TranslateMDISysAccel и др. немогут получить эти сообщения? При любом способе использования GetMessage и PeekMessage возвращают наружу только сообщения из очереди посланных (post) сообщений. Ещё существует очередь отправленных (send) сообщений, и эта очередь обрабатывается целиком внутри GetMessage или PeekMessage независимо от их параметров. Т.е. получается после PeekMessage сообщения можно получить ! Нет, в данном случае PeekMessage просто оставляет сообщение в очереди посланных сообщений, и при следующем вызове GetMessage или PeekMessage будет возвращено оно же. К очереди отправленных сообщений это не имеет никакого отношения. А смысл этого кода в VCL (такое появилось, кстати, только в BDS 2006) в том, что с помощью PeekMessage извлекается информация о самом верхнем сообщении в очереди посланных, но само сообщение при этом не удаляется. Затем по дескриптору окна - получателя этого сообщения определяется, использует ли данное окно кодировку ANSI или Unicode, и затем с помощью PeekMessageA или PeekMessageW извлекается это же сообщение и передаётся на обработку. Но это никак не помогает получить сообщение из очереди отправленных сообщений.  Антон Григорьев

сообщение от автора материала А может это миф, которым пугают детей?:-) Ни разу не видел таких в жизни.:-) В жизни я их тоже, к счастью, не видел. А вот в интернете вопросов от них - предостаточно. Так что одно из двух: либо они действительно существуют, либо кто-то в массовом порядке создаёт виртуальные личности, от имени которых и задаёт такие вопросы. Мне почему-то первый вариант кажется более вероятным :)  Антон Григорьев

Чудес всё-таки не бывает. Как выяснилось, описанное поведение наблюдается только на картах NVIDIA и только в одной "партии" компов. Короче всё дело было в кривом драйвере, после установки свежескачанного драйвера всё встало на свои места: DDB быстрее в 15-25 раз. Эффект "запаздывания" на NVIDIA полностью отсутствует, у меня он только на ATI проявляется. И вообще карты ATI показали в этих тестах намного лучшие результаты, в том числе и за счёт асинхронной работы в режиме DDB.  DRON

Где-то в настройках Windows я находил запрет на использование аппаратного ускорителя, и даже в каком-то тысяча девятьсот лохматом году этим пользовался - на моей карте глючил Corel Draw, пока я это не отключил. Может быть, в этом дело? Это дело я в первую очередь проверил, там всё по максимуму. Меня это тоже удивило, в реальной программе использовал DDB, но после этих экспериментов перешёл на DIB и скорость увеличилась (точнее загрузка проца уменьшилась, частота фиксирована на 20fps) почти в ПЯТЬ раз. Но на некоторых компах наоборот упала примерно в 25 раз (проц загружен на 100% и немного тормозит), причём сильнее всего на стареньком ноуте. Судя по всему, по 2D графике современный процессор обгоняет видео-карту или некоторые производители забили на 2D и улучшают только 3D, а на самом деле чёрт его знает, что там творится. Я всем этим тоже не занимался, но чувствую придётся, так как надо научиться выбирать лучший для данной машины формат. Начну со сбора статистики, а то пара компов это несерьёзно для каких либо выводов. На всех компьютерах, на которых я это тестировал, при относительно небольших количествах повторов измеренное программой время было существенно меньше наблюдаемого. Там на самом деле разница на константу (около 1-2сек), это легко наблюдать поставив в нужных местах "Windows.Beep(440,10);" и, с помощью ручного секундомера, засекать время между "бипом" и концом "мельтешения". Скорее всего, имеет место аппаратная сериализация вызовов и время задержки зависит от максимального размера очереди в видео-карте. Применение GdiFlush и GdiSetBatchLimit(1) результатов не изменили, настройки карты, тоже (там и нет отдельных 2D настроек). Уменьшение "Аппаратного ускорения" приводит к замедлению сразу раз в 25. Всё это проявляется только на тех компах где DDB быстрее DIB, на других вообще ничего, ни от чего не зависит (по крайней мере в разы).  DRON

сообщение от автора материала Мухтар: А что конкретно вы подразумеваете под 3D/2D-заморочками? Насколько мне известно, главные из "2D-заморочек" - это работа с прямоугольными областями, прежде всего заливка и копирование картинок, так что вывод DDB-изображения - это и есть та самая заморочка, которую должна уметь поддерживать любая уважающая себя видеокарта.  Антон Григорьев

сообщение от автора материала DRON: То, что DDB может выводиться на экран медленнее, чем DIB, оказалось для меня большой неожиданностью. Чтобы аппаратный ускоритель, да ещё и с родным форматом работал медленнее, чем чисто программные алгоритмы... Где-то в настройках Windows я находил запрет на использование аппаратного ускорителя, и даже в каком-то тысяча девятьсот лохматом году этим пользовался - на моей карте глючил Corel Draw, пока я это не отключил. Может быть, в этом дело? Вообще, с измерением скорости вывода на экран есть и другие чудеса (в комментариях к примеру я об этом написал). На всех компьютерах, на которых я это тестировал, при относительно небольших количествах повторов измеренное программой время было существенно меньше наблюдаемого. Например, видно, что вывод занимает около трёх секунд, а измерения дают полсекунды или даже меньше. Чем больше количество итераций, тем меньше заметна разница. Причём на разных компьютерах разница становилась незаметной при различных количествах итераций. Я измерял время сначала с помощью GetTickCount, потом прешёл на QueryPermormanceCounter - результаты не изменились. Почему так происходит, я так и не понял. То ли видеокарта при обращении к памяти приостанавливает работу процессора, то ли ускоритель работает параллельно с процессором, то ли ещё что - я не знаю, я плохо знаком со всеми этими аппаратными штучками.  Антон Григорьев

Хотелось бы сказать пару слов по поводу примера "BitmapSpeed". Во-первых, фраза "но вывод DDB на экран всегда существенно быстрее, чем DIB" слишком категорична. На NVIDIA MX 400 (другие пока не проверял) скорость вывода на экран 24bit DIB (в вашем примере именно так) примерно в два раза выше, чем вывод DDB (8bit ещё быстрее), а скорость вывода 32bit DIB один в один совпадает с DDB (скорее всего это один и тот же формат). Во-вторых, не знаете ли вы способ (без проведения тестов конечно) определения, какой тип хранения Bitmap-ов будет быстрее всего работать на заданной видео карте?  DRON

сообщение от автора материала Анониму: не нравится вопрос - игнорируй Не согласен. Почему я не буду игнорировать такие вопросы, я написал здесь: http://www.delphikingdom.com/asp/answer.asp?IDAnswer=35547  Антон Григорьев

to SSV: Есть люди, которые научились бросать компоненты на форму и считают себя крутыми программистами. Считают что этого достаточно. Есть люди, которые пока умеют только кидать компоненты на форму, но стремятся узнать больше. Сначала они выглядят одинаково, задавая один и тот же вопрос: "Где найти такой-то компонент". Но вот на предложение сделать такой компонент самостоятельно следуют ответы двух типов. И ответ позволяет достаточно точно отнести автора либо к первым, либо ко вторым. Вторые сразу начинают расспрашивать, как это сделать, где прочитать. А первые продолжают нудно тянуть: "А готового компонента нет?". Вот этих первых Антон, мягко выражаясь, недолюбливает (да и не он один) и называет компоненто-на-форму-кидателями. Так как термин он сочинил сам, то такого ресурса Вы не найдете. Разве что Антон разместит в интернете словарь собственных терминов :-)  Geo

Отличная статья! Такой концентрации полезных сведений в сочетании с доступностью изложения и качеством информации я не встречал ни в одной книге по Delphi. Спасибо, Антон.  Александр Малыгин

сообщение от автора материала SSV: Я ещё раз обясняю: компоненто-на-форму-кидатель - это тот, кто считает, что кидать на форму компоненты - этого вполне достаточно. Если же человек умеет только кидать компоненты на форму, но понимает, но при этом понимает, что это ещё не программирование - он не компоненто-на-форму-кидатель, он - начинающий программист, т.е. человек, вполне достойный уважения. И я это в предыдущем сообщении ясно сказал. Не понимаю, откуда такое стремление найти в моих словах какой-то скрытый оскорбительный смысл.  Антон Григорьев

сообщение от автора материала SSV: Это кого же я оскорбил? "Компоненто-на-форму-кидателей"? Так эта статья точно не на них рассчитана. "Компоненто-на-форму-кидатель" в моём понимании - это человек, который считает, что программирование в Delphi исчерпывается киданием на форму компонентов и установлением взаимосвязей между ними, а все нестандартные задачи пытается решить поиском подходящих компонентов в интеренете. Таких людей я не уважаю, и если даже оскорбил их, нисколько в этом не раскаиваюсь. А статья ориентирована на тех, кто уже понимает, что кроме использования готовых компонентов можно делать ещё много чего, но пока не знает, как это делать. Таких людей оскорблять у меня нет никакого желания - все мы через это прошли, никто с умением программировать не родился. Одним словом, я руководствуюсь пословицей "не стыдно не знать, стыдно не учиться". А сейчас, к сожалению, очень много развелось таких "программистов", которые именно не учатся.  Антон Григорьев

сообщение от автора материала Так, волна комментариев закончилась, пора отвечать :) Анониму: Хотелось бы что бы в демо примерах появились проекты которые бы использовали классы TCoordLabel и TLine (без их предварительной установки в делфи), т.е. экземпляры классов создавались бы кодом. Честно говоря, не вижу большого смысла в этом. Эффектность этих примеров (особенно TLine) во многом определяется тем, что их можно установить в палитру компонентов и бросить на форму - без этого впечатление от них будет неполным. Так что пока я не вижу необходимости делать такие проекты. Но ещё подумаю об этом. checker'у: Второе утверждение не совсем неверно, так делается "как правило", но не всегда. Владельца компонента (свойство Owner) можно поменять вручную с помощью методов InsertComponent() и RemoveComponent(). Согласен, тут я поторопился с утверждением. При случае подправлю. Константину Цветкову: думаю, что идти нужно от WinAPI к Delphi. То есть, сначала изучить WinAPI (в  плавании по сухому), а потом смотреть как это реализуемо в Dephi. В общем-то, Geo уже ответил. Добавлю только, что в 99% случаев использование API при программировании на Delphi сводится именно к API-вставкам в VCL-приложение. Вот и давайте учиться тому, что мы потом будем применять на практике - так будет легче добраться до основ, с которых вы предлагаете начать.  Антон Григорьев

>>> Я, например, узнал WinAPI раньше Delphi, поскольку программировал тогда на VO, FiveWin. А я программировать в машинных кодах стал раньше, чем на ассемблере :-) Но это же не повод, рекомендовать данный подход в качестве стандарта для обучения :-)  Geo

to Константин Цветков Изучать с нуля Win API?! Удовольствие ниже среднего. Пока не наберешь критическую массу знания, программу не напишешь. Лучше уж слепить программку на Delphi, а потом совершенствовать ее, внедряя последовательно функции из Win API.  Geo

Добавьте свое cообщение

Вашe имя:  [Войти] Ваш адрес (e-mail): На Королевстве все адреса защищаются от спам-роботов контрольный вопрос: Вода мокрая или сухая? в качестве ответа на вопрос или загадку следует давать только одно слово в именительном падеже и именно в такой форме, как оно используется в оригинале. Надоело отвечать на странные вопросы? Зарегистрируйтесь на сайте. Оценка содержания Содержит полезные и(или) интересные сведения Ничего особенно нового и интересного Написано неверно (обязательно укажите почему) Оценка стиля изложения Все понятно, материал читается легко Есть неясности в изложении Непонятно написано, трудно читается Текст:                        вопрос Круглого стола № XXX вопрос № YYY в тесте № XXX Рыцарской Квинтаны сообщение № YYY в теме № XXX Базарной площади обсуждение темы № YYY Базарной площади     Правила оформления сообщений на Королевстве