Pull to refresh

Добавляем watermark к изображению

.NET *
Привет, Хабрахабр!
Вчера, прочитав статью SergeyVoyteshonok, посвященную отрисовке логотипа сайта или компании (проще говоря, «водяного знака») на загружаемых пользователями изображениях, я был удивлен некоторой тяжеловесностью предложенного автором решения.
Тогда я пообещал немного поэкспериментировать и предложить более рациональный вариант.

Вот, что у меня получилось
Total votes 53: ↑46 and ↓7 +39
Views 6.3K
Comments 27

Печать из Mac OS по WiFi на GDI-принтер

Lumber room
Чудные win-принтеры вообще железки капризные при попытках их использовать под *NIX и по сети, а тут возникла необходимость подключить HP LaserJet 1000 к конструктору D-Link DIR-320 для печати без проводов. Принт-сервер из коробочки вроде эту возможность не поддерживает, комплект от йота-самоделкиных не проверял.
Мой рецепт под катом.
Читать дальше →
Total votes 13: ↑11 and ↓2 +9
Views 1.6K
Comments 6

«Намертво прибитая к ядру» графическая подсистема

Development for Windows *


То, что принято называть «графикой в ядре» обычно относится к win32k. Win32k.sys представляет собой ядерную часть графической подсистемы. Загружается пользовательским процессом smss.exe в процессе инициализации всех остальных подсистем. Путь к исполняемому образу для «kmode» подсистемы прописан здесь:


Как же это происходит?
Читать дальше →
Total votes 271: ↑246 and ↓25 +221
Views 7.2K
Comments 120

Масштабный выпуск новостей ReactOS № 83

Open source *
Translation
image

Использование памяти в GDI


image
В процессе переписывания диспетчера поддержки интерфейса графических устройств (GDI), Тимо Кройцер (Timo Kreuzer) столкнулся с тем, что можно назвать не иначе, как чудовищная растрата памяти. Количество выделяемой памяти для создаваемых объектов составляло всегда полную страницу, т.е. 4 Кб, вне зависимости от того, нужен ли объекту такой большой объём памяти для хранения своих атрибутов. Это приводит к значительному расходу памяти впустую, а также к расходованию адресов памяти. Тимо предполагает, что это является одной из причин, приводящих к утечке в диспетчере задач множества страниц памяти за раз. В Win32k имеется механизм кэширования таких выделений, который, по всей видимости, не использует освобожденные страницы повторно, поэтому в течение некоторого количества времени вся память системы может быть исчерпана.
Читать дальше →
Total votes 66: ↑62 and ↓4 +58
Views 884
Comments 15

Поиск утечки GDI объектов: Как загнать мастодонта

.NET *System Programming *Debugging *Development for Windows *
Translation
Строго говоря именно это оригинальный текст статьи, а в блоге уже перевод. Здесь статья публикуется чуть позже и только потому получает бирку перевод.

В 2016 году, когда большинство программ выполняются в песочницах, из которых даже самый некомпетентный разработчик не сможет навредить системе, странно сталкиваться с проблемой, о которой дальше пойдет речь. Если честно, я надеялся, что она ушла в далекое прошлое вместе с Win32Api, но недавно я с ней столкнулся. До этого я лишь слышал жуткие байки старых более опытных разработчиков, что такое может быть.

Проблема


Утечка или использование слишком большого числа GDI объектов.

Симптомы:


  • В Task Manager на вкладке Details колонка GDI objects показывает угрожающие 10000(Если этой колонки нету, ее можно добавить, кликнув на заголовке таблицы правой кнопкой и выбрав пункт Select Columns)
  • При разработке на C# или другом языке выполняемом CLR полетит исключение, не блещущее конкретикой:
    Message: A generic error occurred in GDI+.
    Source: System.Drawing
    TargetSite: IntPtr GetHbitmap(System.Drawing.Color)
    Type: System.Runtime.InteropServices.ExternalException

    Также при определенных настройках или версии системы исключения может и не быть, но Ваше приложение не сможет нарисовать ни единого объекта.
  • При разработке на С/С++ все методы GDI вроде Create%SOME_GDI_OBJECT% стали возвращать NULL
Читать дальше →
Total votes 45: ↑45 and ↓0 +45
Views 14K
Comments 21

Google опять раскрыла незакрытую уязвимость в Windows

IT-companies


Второй раз за три месяца разработчики из компании Google раскрыли баг в операционной системе Windows до того, как Microsoft выпустила патч. Теоретически, теперь несколько недель кто угодно может эксплуатировать критическую уязвимость, доступную на всех компьютерах под Windows.

Считается, что публичное разглашение информации — самый эффективный способ поторопить вендора с выпуском патча. Таким образом Google оказывает услугу всем пользователям, заставляя Microsoft пошевелиться.

В данном случае уязвимость обнаружена в подсистеме Windows GDI (Graphics Device Interface), то есть в библиотеке gdi32.dll.
Читать дальше →
Total votes 27: ↑26 and ↓1 +25
Views 23K
Comments 29

Невызванная функция замедляет программу в 5 раз

IT systems testing *Google Chrome Designing and refactoring *Development for Windows *
Translation
Замедляем Windows, часть 3: завершение процессов



Автор занимается оптимизацией производительности Chrome в компании Google — прим. пер.

Летом 2017 года я боролся с проблемой производительности Windows. Завершение процессов происходило медленно, сериализованно и блокировало системную очередь ввода, что приводило к многократным подвисаниям курсора мыши при сборке Chrome. Основная причина заключалась в том, что при завершении процессов Windows тратила много времени на поиск объектов GDI, удерживая при этом критическую секцию system-global user32. Я рассказывал об этом в статье «24-ядерный процессор, а я не могу сдвинуть курсор».

Microsoft исправила баг, и я вернулся к своим делам, но потом оказалось, что баг вернулся. Появились жалобы на медленную работу тестов LLVM, с частыми подвисаниями ввода.

Но на самом деле баг не вернулся. Причина оказалась в изменении нашего кода.
Читать дальше →
Total votes 75: ↑73 and ↓2 +71
Views 42K
Comments 49

Об утечках GDI и о важности удачи

Google Chrome Development for Windows *
Translation

В мае 2019 года меня попросили взглянуть на потенциально опасный баг Chrome. Поначалу я диагностировал его как неважный, потратив таким образом впустую две недели. Позже, когда я вернулся к расследованию, он превратился в причину номер один вылетов процесса браузера в beta-канале Chrome. Упс.

6 июня, в тот же день, когда я осознал свою ошибку в интерпретации данных вылетов, баг был помечен как ReleaseBlock-Stable. Это означало, что мы не сможем выпустить новую версию Chrome для большинства пользователей, пока не разберёмся, что происходит.

Вылет происходит, потому что у нас заканчивались объекты GDI (Graphics Device Interface), но мы не знали, какого типа эти объекты GDI, диагностические данные не давали никаких подсказок о том, где возникает проблема, и мы не могли её воссоздать.

Многие люди из нашей команды упорно работали над этим багом 6-7 июня, они тестировали свои теории, но так и не продвинулись вперёд. 8 июня я решил проверить свою почту, и Chrome сразу же вылетел. Это был тот самый сбой.

Какая ирония. Пока я искал изменения и исследовал отчёты о сбоях, пытаясь понять, что же могло заставлять процесс браузера Chrome вызывать утечку объектов GDI, количество объектов GDI в моём браузере неумолимо стремилось вверх, и к утру 8 июня превзошло волшебное число — 10 000. В этот момент одна из операций выделения памяти под объект GDI завершилась ошибкой и мы намеренно обрушили браузер. Это была невероятная удача.
Читать дальше →
Total votes 19: ↑18 and ↓1 +17
Views 2.6K
Comments 1