|
|
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
всетаки решил завести отдельный топик. по долгу службы мне необходимо обрабатывать 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. как думаете можно ли оптимизировать алгоритм? тоесть не прибегать к аппаратно зависимой оптимизации. у меня была идея делать проверку не только на salpha==0 (исходный пиксел совершенно прозрачен и обработке не пожлежит) но и на salpha==255 (когда исходный пиксел абсолютно перекрывает результирующий) Но дополнительные проверки в теле цикла реально замедляют работу функции. хотя это нужно обмохговать... думал сделать таблицу соответствий, но она шибко огромная получилась бы.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 17:00 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Насчёт проверки условий. Я провёл такой эксперимент: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Меня удивило, что вынесение объявления j за пределы цикла совершенно не меняет времени выполнения. А по существу пока ничего не придумывается... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2004, 12:49 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Ой ВэйНасчёт проверки условий. Я провёл такой эксперимент: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Меня удивило, что вынесение объявления j за пределы цикла совершенно не меняет времени выполнения. А по существу пока ничего не придумывается... а while по быстрее работать будет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2004, 13:05 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Это ещё почему? Ни фига подобного, я попробовал... Хуже другое: в пятницу эти 11 и 8 получались стабильно, а сегодня 8 в обоих случаях :(( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2004, 13:16 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Ой ВэйЭто ещё почему? Ни фига подобного, я попробовал... Хуже другое: в пятницу эти 11 и 8 получались стабильно, а сегодня 8 в обоих случаях :(( Странно у меня прирост от while -ов был значителен ... лень конечно пробовать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2004, 13:33 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Иногда время проверки условия выхода из цикла можно сократить если сравнивать не с константой а с нулем. Но это дает эффект для циклов у которых тело выполняется очень быстро. Правда счетчик пойдет в обратную сторону. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 12:04 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
ну а если слушать моего товарища который сидит по соседсву и контролеры програмает то Код: plaintext 1. 2. 3. 4. 5. хотя не уверен не помню как он говорил :) ш (';') (V),(V),, Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 12:42 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Передай своему товарищу по соседству что for и while это один и тот-же цикл с предусловием. Теоретически они должны генерить один и тот-же машинный код. Вот шаблончик перехода от for к while и наоборот Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 12:59 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Да мне самому интерестно , он еще говорил , так как он охотник за оптимальностью :) ну всмусле в контроллер больше не зальешь чем есть . он говорил , что даже по размеру обьем кода меняется , ладно его увижу , пускай аргуменитрует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 13:21 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Договорились. Буду заглядывать в этот сабж. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 13:26 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
автортак как он охотник за оптимальностью тогда пусть придумает сортировку без jmp ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 17:48 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Sieben автортак как он охотник за оптимальностью тогда пусть придумает сортировку без jmp ;) Хех , а такое вообще возможно ?. я что то пока не представляю как сие сделать . :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2004, 17:52 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
можно немного развернуть цикл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2004, 18:46 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
например, обрабатывать в цикле не один а 4 пиксела? ну, немного это добавит, наверное... однако, это скорее аппаратная оптимизация. А алгоритмически, никак нельзя? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2004, 20:38 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Это слишком похоже на использование технологий MMX. Но ведь ты просил алгоритмическую оптимизацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2004, 21:24 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Я придумал один финт ушами, который должен ускорить это дело процентов на 25. Сейчас нет времени проверить, т.к. надо работать :) Идея такая: не вырезАть отдельно sred/sblue и dred/dblue, а потом их склеивать, а обработать вместе. Код: plaintext 1. 2. 3. 4. 5. 6. К сожалению, с alpha+green это не проходит, т.к. alpha не надо умножать на alpha. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2004, 13:21 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
И, конечно, не надо Код: plaintext 1. 2. 3. а надо Код: plaintext 1. 2. 3. экономится 3-1=2 действия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2004, 13:48 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
реальная тема, спасибо :-) однако надо подумать на тему когда sred<dred или sblue<dblue ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2004, 13:50 |
|
||
|
RGBA+RGBA
|
|||
|---|---|---|---|
|
#18+
Если частные случаи рассматривать когда salpha={0,1,2,4,8...} то можно упростить умножение dblue +=(sblue-dblue)>>8; // когда salpha=1; dblue +=(sblue-dblue)>>4; // когда salpha=8; Только надо прикинуть.. не будет ли оператор if или switch работать медленне чем три целочисленных умножения. Можно сузить сам цикл. К примеру если область ненулевых значений alpha - ограничить прямоугольником. То можно обрабатывать не всю картинку а только фрагмент. Вообще-то эта операция - блиттинг с альфа-каналом может выполнятся самой видекартой. Но это уже уровень программирования библиотек вроде DirectX и OpenGL. Надо только придумать как эти данные видекарточке передать. Но если это реализовать то это будет самая быстрая операция смешивания двух картинок. Тут уж все GDI просто отдыхают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2004, 12:47 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=32710386&tid=2034374]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
131ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 416ms |

| 0 / 0 |
