Как масштабировать используя GPU?

← →
wizarden © (2005-09-20 08:31) [0]

Хочется масштабировать (уменьшать, увеличивать) изображения из TImage используя аппаратное ускорение графического процессора. Т.е. надо из виндового приложения - не игра - это делать. Как это сделать? Примеры приветствуются.

← →
Sapersky (2005-09-20 11:29) [1]

Ну а как обычно используется GPU? OpenGL или Direct3D и вперёд.
У меня есть пример для D3D7, правда без TImage.

Или, может быть, проще обойтись программным масштабированием, если как следует всё оптимизировать. См., например, модуль FastSize.pas отсюда:

http://prdownloads.sourceforge.net/skinner/FastLib.zip?download

Или подождать очередной Windows, в котором аппаратное ускорение обещают встроить в GDI :)

← →
wizarden © (2005-09-20 14:50) [2]

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

← →
WondeRu © (2005-09-20 15:46) [3]

wizarden © (20.09.05 14:50) [2]
ну не совсем хардварно... но бибилиотека GDI+ умеет это делать замечательно... *.pas файлы на progdigy.com

ну а для хардварного только DirectDraw... блиттинг называется это там...

а в простом API это StretchBlt

← →
Sapersky (2005-09-20 16:09) [4]

Нет, для миниатюр аппаратное ускорение лучше не использовать.
Если исходная картинка большая, время на преобразование её в нужный формат текстуры (или поверхности) наверняка превысит время софтверного уменьшения (т.к. и в том и другом случае требуется обработать каждый пиксель исходного изображения, но при уменьшении размер результирующей картинки меньше -> меньше обращений к памяти). Это при уменьшении без сглаживания - но оно ИМХО и не нужно. Или можно просто слегка размазать миниатюру блюром (быстро, т.к. размер маленький) - вот вам и сглаживание :)

Так что - FastLIB, GDI(StretchBlt), GDI+.
Я тестировал первые два - со сглаживанием быстрее FastLIB, без сглаживания - примерно одинаково. Насчёт GDI+ не знаю.

Ещё, jpeg (большинство картинок ведь jpeg) можно грузить не полностью, а 1/2, 1/4 и т.д. Да и программное уменьшение в "круглое" кол-во раз (если самому написать оптимизированную функцию) должно быть быстрее.

← →
wizarden © (2005-09-20 16:19) [5]

... а потом миниатюры надо увеличивать до размера экрана. Вообщем задачи как уменьшать так и увеличивать. Странно, что выйгрыша нет, вроде бы такая мощь, а задача типовая для графики. Ладно посмотрю в сторону указанных библиотек и поищу про блиттинг.

← →
XProger © (2005-09-20 21:58) [6]

http://msdn.microsoft.com/library/en-us/gdi/bitmaps_9cok.asp?frame=true

← →
WondeRu © (2005-09-21 09:17) [7]

wizarden © (20.09.05 16:19) [5]
... а потом миниатюры надо увеличивать до размера экрана. Вообщем задачи как уменьшать так и увеличивать

и еще чтоб картинка полученная из миниатюры была хорошего качества? ;)

← →
Sapersky (2005-09-21 12:09) [8]

Если увеличение/уменьшение (увеличение исходных картинок, я так понимаю, миниатюры без толку увеличивать) - то теоретически из аппаратного ускорения можно извлечь какую-то выгоду... Но это будет ничуть не проще, чем грамотная оптимизация софтверных алгоритмов. Скорее даже сложнее - в аппаратной графике масса нюансов, которые непосвящённый будет постигать долго и мучительно.
Поэтому рекомендую начать с программной обработки - по при этом чётко представлять, что происходит с картинкой, сколько раз и как она обрабатывается. Желательно понимать, что происходит на уровне пикселей - поэтому и рекомендую FastLib (она opensource).
Обратить внимание на оптимизацию загрузки jpg - это место может стать главным тормозом. IJL, которая имеется в комплекте с FastLIB, грузит быстрее стандартного модуля jpеg.pas, может грузить отдельные фрагменты картинки.

какая выгода из аппаратного ускорения? сначала придется преобразовать изображение в текстуру, потом перегнать ее в видеопамять, потом все это наоборот. к тому же, масштабирует видюха только с линейной интерполяцией, сравните в фотошопе - что луше, линейная или кубическая.
баловство все это.

← →
Sapersky (2005-09-22 13:33) [10]

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

Может, конечно, и баловство. Но MS зачем-то влез в это дело... :)

← →
Дмитрий Белькевич (2005-09-25 16:18) [11]

>какая выгода из аппаратного ускорения? сначала придется преобразовать изображение в текстуру, потом перегнать ее в видеопамять, потом все это наоборот. к тому же, масштабирует видюха только с линейной интерполяцией, сравните в фотошопе - что луше, линейная или кубическая.
баловство все это.

какая нафиг текстура - поверхности, и только они. только реальная польза от них, если через них же и выводить на экран. если гонять данные по шине - польза сомнительная. оно хоть и агп, но всё равно - если всё в видеопамяти, то гораздо быстрее крутится.

← →
Sapersky (2005-09-26 11:14) [12]

На некоторых картах (интегрированные на i815, например) текстуры аппаратно масштабируются, а поверхности нет.
Ещё, хотя к теме вопроса это не относится - с текстурами возможны дополнительные спецэффекты - вращение, блендинг и прочее.

Как масштабировать используя GPU? Найти похожие ветки