Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / C++ [игнор отключен] [закрыт для гостей] / RGBA+RGBA / 19 сообщений из 19, страница 1 из 1
14.09.2004, 17:00
    #32694252
alex_k
alex_k
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
всетаки решил завести отдельный топик.
по долгу службы мне необходимо обрабатывать TGA файлы. в основном наложение друг на друга с учетом прозрачности.

вот кусок кода, который это делает:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
 DWORD* dmem=(DWORD*)timg->mem;
 DWORD* smem=(DWORD*)mem;
...
...
   DWORD ps=smem[ 0 ];
   int salpha =(ps>> 24 ) & 0xff;
   if (salpha!= 0 )
   {
    sred  =(ps>> 16 ) & 0xff;
    sgreen=(ps>> 8  ) & 0xff;
    sblue =(ps>> 0  ) & 0xff;
    DWORD pd=dmem[ 0 ];
    dalpha =(pd>> 24 ) & 0xff;
    dred  =(pd>> 16 ) & 0xff;
    dgreen=(pd>> 8  ) & 0xff;
    dblue =(pd>> 0  ) & 0xff;
    dblue +=((sblue-dblue)*salpha)>> 8 ;
    dgreen+=((sgreen-dgreen)*salpha)>> 8 ;
    dred  +=((sred-dred)*salpha)>> 8 ;
    dalpha+=salpha;
    if (dalpha> 255 )dalpha= 255 ;
   }
   dmem[ 0 ]=(dalpha<< 24 ) | (dred<< 16 ) | (dgreen< 8 ) | dblue;
это то что происходит внутри цикла по x и y.

как думаете можно ли оптимизировать алгоритм?
тоесть не прибегать к аппаратно зависимой оптимизации.

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

думал сделать таблицу соответствий, но она шибко огромная получилась бы....
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2004, 12:49
    #32702087
Ой Вэй
Ой Вэй
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Насчёт проверки условий. Я провёл такой эксперимент:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
#include <windows.h>

int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
    int j;
    for(int I= 0 ; I< 2000000000 ; I++)
    {
         //if(j != 0) 
            j= 0 ;
    }

	return  0 ;
}
Так оно у меня на компьютере выполняется 11 сек. (в дебаге под отладчиком). А если раскомментировать строку, т.е. присвоение выполняться не будет, то 8 сек.

Меня удивило, что вынесение объявления j за пределы цикла совершенно не меняет времени выполнения.

А по существу пока ничего не придумывается...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2004, 13:05
    #32702141
JibSkeart
JibSkeart
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Ой ВэйНасчёт проверки условий. Я провёл такой эксперимент:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
#include <windows.h>

int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
    int j;
    for(int I= 0 ; I< 2000000000 ; I++)
    {
         //if(j != 0) 
            j= 0 ;
    }

	return  0 ;
}
Так оно у меня на компьютере выполняется 11 сек. (в дебаге под отладчиком). А если раскомментировать строку, т.е. присвоение выполняться не будет, то 8 сек.

Меня удивило, что вынесение объявления j за пределы цикла совершенно не меняет времени выполнения.

А по существу пока ничего не придумывается...

а while по быстрее работать будет :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2004, 13:16
    #32702181
Ой Вэй
Ой Вэй
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Это ещё почему? Ни фига подобного, я попробовал...

Хуже другое: в пятницу эти 11 и 8 получались стабильно, а сегодня 8 в обоих случаях :((
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2004, 13:33
    #32702236
JibSkeart
JibSkeart
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Ой ВэйЭто ещё почему? Ни фига подобного, я попробовал...

Хуже другое: в пятницу эти 11 и 8 получались стабильно, а сегодня 8 в обоих случаях :((

Странно у меня прирост от while -ов был значителен ...
лень конечно пробовать
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2004, 12:04
    #32706013
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Иногда время проверки условия выхода из цикла можно сократить если сравнивать не с константой а с нулем. Но это дает эффект для циклов у которых тело выполняется очень быстро. Правда счетчик пойдет в обратную сторону.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
#include <windows.h>

int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
    int j;
    for(int I= 1999999999 ;I>= 0 ;I --) 
    {
        //if(j !=  0 )
            j= 0 ;
    }
	return  0 ;
}
Если матрица пикселов лежит в памяти в декартовом порядке то использовать координаты x,y нет необходимости. Достаточно указателя.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2004, 12:42
    #32706142
JibSkeart
JibSkeart
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
ну а если слушать моего товарища который сидит по соседсву и контролеры
програмает то
Код: plaintext
1.
2.
3.
4.
5.
int i =  1000000 ;
while ( --i >=0 ) 
{
  ...
}
еще бысрее должно выполница ,
хотя не уверен не помню как он говорил :)


 ш
(';')
(V),(V),,
Код: plaintext
 JS
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2004, 12:59
    #32706216
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Передай своему товарищу по соседству что for и while это один и тот-же цикл с предусловием. Теоретически они должны генерить один и тот-же машинный код. Вот шаблончик перехода от for к while и наоборот

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
<инициализация>
while(<условие>)
{
   <тело>
   <итерационное выр.>
}

равносильно

for(<инициализация>;<условие>;<итерационное выр.>)
{
    <тело>
}
Если твой товарищ докажет что это не так пускай публикует ассемблерные исходники. Будем разбиратся.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2004, 13:21
    #32706294
JibSkeart
JibSkeart
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Да мне самому интерестно ,

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

ладно его увижу , пускай аргуменитрует
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2004, 13:26
    #32706316
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Договорились. Буду заглядывать в этот сабж.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2004, 17:48
    #32707263
Sieben
Sieben
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
автортак как он охотник за оптимальностью
тогда пусть придумает сортировку без jmp ;)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2004, 17:52
    #32707277
JibSkeart
JibSkeart
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Sieben автортак как он охотник за оптимальностью
тогда пусть придумает сортировку без jmp ;)

Хех , а такое вообще возможно ?.
я что то пока не представляю как сие сделать . :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.09.2004, 18:46
    #32709272
Tracer
Tracer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
можно немного развернуть цикл
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.09.2004, 20:38
    #32709411
alex_k
alex_k
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
например, обрабатывать в цикле не один а 4 пиксела?
ну, немного это добавит, наверное... однако, это скорее аппаратная оптимизация.
А алгоритмически, никак нельзя?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.09.2004, 21:24
    #32709443
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Это слишком похоже на использование технологий MMX. Но ведь ты просил алгоритмическую оптимизацию.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.09.2004, 13:21
    #32710306
Ой Вэй
Ой Вэй
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Я придумал один финт ушами, который должен ускорить это дело процентов на 25. Сейчас нет времени проверить, т.к. надо работать :)

Идея такая:
не вырезАть отдельно sred/sblue и dred/dblue, а потом их склеивать, а обработать вместе.

Код: plaintext
1.
2.
3.
4.
5.
6.
sredblue = ps & 0x00ff00ff;
dredblue = pd & 0x00ff00ff;
dredblue += ((sredblue-dredblue)*salpha)>>8 & 0x00ff00ff;

... (green, alpha)

dmem[0]=(dalpha<<24) | (dredblue) | (dgreen<8);

К сожалению, с alpha+green это не проходит, т.к. alpha не надо умножать на alpha.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.09.2004, 13:48
    #32710386
Ой Вэй
Ой Вэй
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
И, конечно, не надо

Код: plaintext
1.
2.
3.
    sgreen=(ps>>8 ) & 0xff;
    dgreen=(ps>>8 ) & 0xff;
    dgreen+=((sgreen-dgreen)*salpha)>>8;
dmem[0]=(dalpha<<24) | (dred<<16) | (dgreen<8) | dblue;

а надо

Код: plaintext
1.
2.
3.
    sgreen=(ps) & 0x0000ff00;
    dgreen=(ps) & 0x0000ff00;
    dgreen+=((sgreen-dgreen)*salpha)>>8 & 0x0000ff00;
dmem[0]=(dalpha<<24) | (dred<<16) | (dgreen) | dblue;

экономится 3-1=2 действия.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.09.2004, 13:50
    #32710391
alex_k
alex_k
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
реальная тема, спасибо :-)
однако надо подумать на тему когда sred<dred или sblue<dblue
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.09.2004, 12:47
    #32711811
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RGBA+RGBA
Если частные случаи рассматривать когда salpha={0,1,2,4,8...} то можно упростить умножение

dblue +=(sblue-dblue)>>8; // когда salpha=1;

dblue +=(sblue-dblue)>>4; // когда salpha=8;

Только надо прикинуть.. не будет ли оператор if или switch работать медленне чем три целочисленных умножения.

Можно сузить сам цикл. К примеру если область ненулевых значений alpha - ограничить прямоугольником. То можно обрабатывать не всю картинку а только фрагмент.

Вообще-то эта операция - блиттинг с альфа-каналом может выполнятся самой видекартой. Но это уже уровень программирования библиотек вроде DirectX и OpenGL. Надо только придумать как эти данные видекарточке передать. Но если это реализовать то это будет самая быстрая операция смешивания двух картинок. Тут уж все GDI просто отдыхают.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / C++ [игнор отключен] [закрыт для гостей] / RGBA+RGBA / 19 сообщений из 19, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 375ms
Закрыть
start [/forum/topic.php?fid=57&mobile=1&tid=2034374]:
 0ms
get settings:
 7ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 37ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 59ms
get tp. blocked users:
 1ms
others: 238ms
total:  375ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]