Вы наверняка слышали о Tox. Напомню: это свободный защищенный p2p протокол для передачи сообщений, аудио и видео потоков между участниками Tox-сети. По сути — это альтернатива скайпу. Когда я впервые услышал о Tox, мой градус неприязни к скайпу был еще не слишком высок, но я уже начал поиск альтернатив. Мне очень понравилась идея, лежащая в основе Tox: мы пишем протокол со всеми нужными плюшками, а вы пишете к нему клиенты. Когда появились первые клиенты для сети Tox, я подумал: «черт возьми, я смогу сделать это не хуже!». Вобщем, подталкиваемый неприязнью к скайпу, я взялся за проект мессенджера своей мечты. Сейчас, когда в моем локальном hg-репозитории первому комиту исполнилось 19 месяцев и был сделан 414-й комит, я наконец то созрел до того, чтобы рассказать об этом клиенте широкой аудитории Хабра.

Я пишу мультипротокольный (но не мультиплатформенный, увы, сейчас только windows) мессенджер, который пока что поддерживает только протокол TOX. Но речь не о мессенджере, а о его интерфейсе, а если точнее, об основной его функции — AlphaBlend. Да, я решил написать свой велосипед GUI. Ну а какой современный GUI без полупрозрачных элементов и плавных закруглений? Поэтому остро встала необходимость смешивать изображения с учетом полупрозрачности, т.е. альфа-смешивание или alpha blending. К счастью, в windows GDI такая функция имеется — AlphaBlend. Работает как надо, делает то что нужно. Но я тот еще строитель велосипедов, и мне стало интересно, смогу ли я написать такую же функцию, но более быструю. Результат моих трудов под катом.

Эта статья написана прежде всего для программистов C/C++, использующих в своей работе Visual Studio 2013. Поскольку я, как говорится, totally windows guy, то я не могу оценить полезность этой статьи для программистов, не использующих эту среду в своей работе. Итак.

Не секрет, что стандартный аллокатор new/delete/malloc/free в языке C/C++ не блещет быстродействием. Конечно, всё зависит от реализации, но, если говорить об оной от компании Microsoft, то это факт. Кроме того, стандартная реализация аллокатора обладает еще одним фатальным недостатком — фрагментацией памяти. Если в вашей программе происходят частые выделения/освобождения памяти, вы можете обнаружить, что спустя несколько часов работы ваша программа упала по причине нехватки памяти, хотя свободной памяти еще достаточно — просто в результате фрагментации в пуле аллокатора не осталось свободного участка достаточного размера. (Это, кстати, абсолютно реальный случай, который произошел на одном из проектов, в котором я принимал непосредственное участие.)