Въпрос относно Renderer::drawImage()

Във форума е въведено ограничение, което позволява на потребителите единствено да разглеждат публикуваните въпроси.

MartinBG 4803 Точки

Въпрос относно Renderer::drawImage()

В предложеното решение, ако има opacity < 255 извикваме SDL_SetTextureAlphaMod преди (сетваме новото opacity) и след (връщаме на 255) извикването на SDL_RenderCopyEx .

Ако съм разбрал правилно, идеята е че промяната на alpha е "скъпа" операция и искаме да го правим само тогава, когато е необходимо.

Днес разгледах кода на SDL и не успях да открия потвърждение на горното.

SDL_Texture e flyweight object, не много по-различeн от нашите DrawParams, а промяната на alpha на практика е просто сетване на един Uint8 от тази структура през SDL_SetTextureAlphaMod:

    texture->a = alpha;

По-нататък alpha стойността не се използва извън SDL_Texture и се подава заедно с всички останали параметри надолу към "желязото", което предполага, че при "рисуването" винаги се използва текущата ѝ стойност.

Ако горното е вярно, не виждам причина, поради която да не се опрости рисуването до следните две безусловни операции:

1. Сетване на alpha с SDL_SetTextureAlphaMod винаги, без значение каква е новата и старата ѝ стойност

2. Рисуване с SDL_RenderCopyEx

Opacity-то би трябвало винаги да е правилното, тъй като всяка картинка си имa свои DrawParams.

void Renderer::drawImage(SDL_Texture* const texture, const DrawParams& drawParams) const {
  if (EXIT_SUCCESS != texture::setAlphaTexture(texture, drawParams.opacity)) { //change opacity
    // "Texture::setAlphaTexture() failed for rsrcId: ", drawParams.rsrcId
  }

  draw(texture, drawParams);
}

Какво изпускам?

Тагове:

07/11/2021 22:40:59 C++ Applications Development

j.petrov_90 373 Точки

Привет, MartinBG,

Благодаря за ценното включване.
Връщаш ме няколко години назад (от тогава не съм се ровил в source-а на SDL).
Беше ми интересно как са имплементирали shader-ите :)

Ако това, което казваш е наистина вярно:
SDL_Texture e flyweight object, не много по-различeн от нашите DrawParams, а промяната на alpha на практика е просто сетване на един Uint8 от тази структура през SDL_SetTextureAlphaMod:

Не би следвало да има проблем да използваме предложената имплементация.

Не си прав, обаче, че стойността на alpha не се ползва повече.
Същата функция се извиква за native texture-а на използвания graphical backend
https://github.com/libsdl-org/SDL/blob/25f9ed87ff6947d9576fc9d79dee0784e638ac58/src/render/SDL_render.c#L1416

Другото, което мe притеснява, е че тази функция прави няколко call-a по intenal code-a на SDL.
Включително и някакъв sanity checking с това макро CHECK_TEXTURE_MAGIC(texture, -1);

Можем изобщо да си спестим тези няколко функции за всеки draw call като изобщо не го правим.
Ще го правим само тогава, когато има нужда.

Накрая, но не на последно място - за да променим alpha на един Texture, ние трябва да сме активирали неговия alphaModulation (да сме сменили blending mode-a).

В имлементацията, която предлагаш няма да разберем дали този Widget има активиран blending mode или не.

Поздрави

08/11/2021 11:16:50 08/11/2021 15:26:16

MartinBG 4803 Точки

Благодаря за отговора!

Прегледах отново кода на SDL в контекста на коментарите ти.

native e пойнтър към SDL_Texture, създаден заедно с основната текстура от SDL_CreateTexture и - доколкото разбирам, определя вътрешната структура на данните (Pixel Format). Рекурсивното извикване на SDL_SetTextureAlphaMod само ъпдейтва alphat-a ѝ, без да прави модификации по данните или да извиква други методи.

CHECK_TEXTURE_MAGIC е "прост" валидиращ макрос:

#define CHECK_TEXTURE_MAGIC(texture, retval) \
    SDL_assert(texture && texture->magic == &texture_magic); \
    if (!texture || texture->magic != &texture_magic) { \
        SDL_SetError("Invalid texture"); \
        return retval; \
    }

В проекта модифицирането на opacity става през Widget::setOpacity където има проверка за blending mode-a и предложената промяна не се отразява на това. Ако модифицираме индиректно DrawingParams#opacity на Widget-a, извикването на SDL_RenderCopyEx просто ще върне грешка, която ние логваме.

Можем изобщо да си спестим тези няколко функции за всеки draw call като изобщо не го правим.
Ще го правим само тогава, когато има нужда.

Това е безспорно така.

Смяната на аlpha изглежда "евтина" операция според кода на SDL_SetTextureAlphaMod, но остава овърхеда от извикването ѝ.

Разликата е дали искаме да контролираме това от нашия код (никакво или с двойно извикване на setAlpha) или винаги да викаме setAlpha и да оставим валидациите и оптимизациите на SDL библиотеката.

08/11/2021 15:10:59

j.petrov_90 373 Точки

Прав си, да.

Ако мога да върна времето назад, когато преподавах лекцията - най-вероятно щях да избера твоя подход.
Причината е, че дори и с няколко микрона по-бавен - той е по-интуитивен и най-вече е beginner friendly.
При по-малко количество информация - аудиторията има по-голям шанс да го разбере.

Нищо де. От положителна страна накарах курсистите да се замислят, че flyweight + shared source (image) не е само "цветя и рози" :)

Поздрави

08/11/2021 15:32:51

MartinBG 4803 Точки

Като за финал по темата ще вметна, че на разположение имаме и този метод: SDL_GetTextureAlphaMod - code, с който можем да проверим текущата стойност на alpha mod-a на текстурата и да го сравним със стойността от DrawParams. Честно казано, очаквах в SDL_SetTextureAlphaMod да има подобна проверка, но явно авторите са преценили, че ъпдейта на alpha-та е достатъчно лек, за да се налага подобна оптимизация.

08/11/2021 22:43:21