No, operace typu putpixel() a getpixel() mohou byt obecne dost pomale, viz treba WinAPI funkce SetPixel() a GetPixel() - pomerne inteligentni, ale neskutecne pomale funkce. Vy vsak nemusite pracovat primo z obrazovou pameti, postaci si do bufferu ulozit maximalne dva obrazove radky a na nich tuto filtraci provadet. Pokud by byl v bufferu ulozen cely dekomprimovany obrazek, je naprogramovani putpixel() i getpixel() pro grayscale pixmapy pomerne jednoduche:
//-----------------------------------------------------------------------------
// Zmena barvy pixelu na zadanych souradnicich
//-----------------------------------------------------------------------------
void putpixel(pixmap *p,
const unsigned int x, // pozice pixelu v pixmape
const unsigned int y,
const unsigned char w) // barva pixelu
{
int pos;
// zde se vyuziva zkraceneho vyhodnoceni vyrazu - pokud plati !p, nic se dale netestuje
if (!p || !p->pixels || x>=p->width || y>=p->height) return;
pos=(x+y*p->width);
p->pixels[pos]=w;
}
//-----------------------------------------------------------------------------
// Precteni barvy pixelu na zadanych souradnicich
//-----------------------------------------------------------------------------
unsigned char getpixel(pixmap *p,
const unsigned int x,
const unsigned int y)
{
int pos;
// zde se vyuziva zkraceneho vyhodnoceni vyrazu - pokud plati !p, nic se dale netestuje
if (!p || !p->pixels || x>=p->width || y>=p->height) return 0;
pos=(x+y*p->width);
return p->pixels[pos];
}
prekladac by nemel mit problemy s "inliningem" techto funkci, pokud ano, staci prepsat do maker.
Dulezite je, ze se jedna POUZE o radkove (resp. "dvouradkove") filtry a to jeste o filtry realizovatelne "zleva-doprava", tj. presne ve smyslu nejrychlejsiho adresovani operacni pameti. Jine usporadani by melo dost podstatny vliv na vykonnost.