MMX масштабироование изображений

вроде, как недавно активно обсуждался
"Вышел KSquirrel 0.7.1", там есть
"масштабирования RGBA изображений" на основе GL
- оттуда и выдрать кусок кода - будет быстрее, чем с MMX.
а вообще-то их огромное кол-во ...

Если на GL, то это абсолютно бесполезный пример, т.к. масштибирует/клипает изображение именно OpenGL, и на выходе он ничего не отдаёт (жадный). Ты предлагаешь 9000x9000 изображение грузить в видеопамять встроенной видюхи ? :)

>>а вообще-то их огромное кол-во

ну, например, именно с MMX.

да все :) на сколько важен RGBA, а не ARGB?

на клиенте (то бишь без Х севера)
gdk-pixbuf, cairo, Qt's arthur, думаю и libgd,
мы используем libAfterImage, посмотреть src mpegplayer ...
и это те, которые "на слуху", скорее всего на порядок больше.

В смысле *растровый* рисунок масштабировать средствами *векторного* движка GL?

А что, OpenGL перестал поддерживать тектсуры?

О, боги! Ради (интер-)экстра-поляции использовать такие сложные вещи?! Там, наверняка, простые формулы...

Растерные операции в OpenGl предусмотрены, смотреть в сторону glRaster*

Посмотри в сторону libswscale из пакета ffmpeg...

Зачем нужно смотреть в какую-то сторону, если это всего лишь 2D-задача, где central process only решение будет и эффективнее и проще? А смотреть по-моему нужно с сторону Cairo или Arthur. Любой уважающий себя 2D engine такую задачу выполнять должен, например, GDI.

>А смотреть по-моему нужно с сторону Cairo или Arthur. Любой уважающий себя 2D engine такую задачу выполнять должен, например, GDI.

Бесспорно, это достаточно простая задача. Но исходный вопрос звучал об её реализации средствами MMX. Потому и посоветовал взглянуть на libswscale, ибо AFAIK он как раз поддерживает ускорение с помощью MMX.

всем спасибо, буду смотреть.

Посмотри еще AGG http://antigrain.com/ - очень шустрая штука.

лично мне gdk-pixbuf понравилась

imlib2, насколько я знаю.

>>gdk-pixbuf

там используется уже давно неподдерживаемый pixops, который иногда (редко) может портить альфа канал.

кстати я тут на днях экспериментировал с векторами и кватернионами, имплементируя их на sse и руками.
руками оказалось быстрее...видимо я просто не умею готовить sse :(
либо в случае с имплементом руками - gcc сам оптимизирует под sse
лучше, чем я пишу (флаги были -msse -mfpmath=sse)

+

http://www.linux.org.ru/view-message.jsp?msgid=1849391

> http://antigrain.com/ - очень шустрая штука.

в antigrain нет ММХ, и ни какая она не "шустрая штука",
когда речь идет о растровых изображениях.
Она предназначена для векторной графики.

Любителям оптимизации (ответ эксперта, отрывок из моей личной переписки) :)

commented out code in alpha-blending was my attempt to accelerate it,
but it turns out that original int math was way faster, so I stuck to it.
Generally using mmx/sse does not seems to be worth the effort, compiler
does very good job optimizing code for particular CPU. There is no
noticeable difference untill you get in range of about 1000000 ops, and
even then its just a few milliseconds.

Полностью не согласен с предыдущим автором. Значит этот экспер не умеет писать на ассмблере.

Проверяется очень просто: берём mplayer (именно оттуда растёт libswscale), компилируем под свою железку, смотрим фильм с программным масштабированием на большой монитор, смотрим в статус лайне загрузку процессора на отображение видео. Потом перекомпилируем mplayer (distclean не забудьте) без поддержки mmx, и, о ужас, всё стало работать в ~2.5 раз медленее! Более точные цифры вам даст oprofile.

ImageMagick?

> Полностью не согласен с предыдущим автором.

известно, что самая "затратная операция" - BitBltting (копирование контента на экран). подозреваю, что имненно здесь основной выигрыш
от MMX.