View Full Version : FillMargins

2nd April 2003, 22:52
I was wondering if you could spare a bit of time and add some comments to your code:

for (pDestW=pDestM; pDestW <= pDestB; pDestW += dst_pit)
mov edi, pDestW
mov ecx, fLeftW
mov al, byte ptr[edi+ecx]
rep stosb

mov edi, pDestW
add edi, Roffs
mov al, byte ptr[edi]
inc edi
mov ecx, fRightW
rep stosb

as it looks like a very "simple" piece of code and could maybe prompt some of us "slow" plugin writers to start speeding up our filters:)

2nd April 2003, 23:25
"Free from memory". Actually "rep" command is quite unusual to use, since there are often (although not often in this case) faster ways of moving data (mmx).

Clears the direction of a "rep". "std" will make it go the opposite way.

>mov edi, pDestW
Move pointer to destination into edi register. ESI is always destination register for "rep"

>mov ecx, fLeftW
Move "length" or "number of bytes" into ecx. This is always the counter register for rep.

>mov al, byte ptr[edi+ecx]
Move value of the byte placed at (edi+ecx) into al.

>rep stosb
"Repeat Store Byte". This function will store one byte, increase edi by one and decrease ecx. This will repeat until ecx is 0.

The rest of the code "explains itself", except:

>add edi, Roffs
Adds the value of the Roffs variable to the edi register.

>inc edi

3rd April 2003, 05:30
What he says. ;)

Only other comment is that stosb is the fastest way to fill a variable amount of memory with copies of a sinlge byte only as long as you are doing only a few of them. In this case I could fill the bytes faster than the function call overhead to something that could would be more efficient if it was a longer string. But I'm assuming the left and right margins are usually < 16 bytes. Note my use of memcpy probably wasn't optimal, just lazy.

@Simon -

I wasn't sure. Does your BorderControl already do this same thing?

- Tom

3rd April 2003, 21:00
Thanks for comments - didn't understand your 1 words - "Free from memory" :confused:

I think your
FillMargins(5,7,2,0) # (left, top, right, bottom)

is the same as my


but it'll be a lot slower of course (mine I mean :) )

Mines more intended to deal with poor VHS captures from poor TV broadcasts sourced from poor VTR machines ;)


4th April 2003, 09:00
Originally posted by siwalters
Thanks for comments - didn't understand your 1 words - "Free from memory" :confused:

It just means that I'm not 100% sure it actually is like it is, but I seem to recall that's how it is.