MultiWin and imglib

[KenDown]

In a post on the Discussion Group Richard referred to a procedure which gave you the size of your picture. PROC_imgSize() Having become somewhat familiar with imglib over the last week or so I was a little surprised and queried this with him. It turns out that it is a new procedure which was not in the download from the Files area of the Discussion Group. I was pleased to note that the dimensions are found exactly as I described in my documention but with a procedure call to slow things down a fraction. (And, of course, please note that my comments only refer to imglib for BB4W).

Also note that the library for BB4W is now IMGLIB and no longer IMGLIB_W as was the case previously.

[KenDown]

Richard's modified imglib, which includes the PROC_imgSize() routine, does exactly the same as my suggestion in my documentation:

width=I%!4:height=i%!8

However this returns the full size of the picture, which may be less than useful if you have used the scale facility to alter the size of your picture. A more useful procedure is the following:

Code: Select all

      DEFPROC_imgSize(I%,s,t,RETURN w,RETURN h)
      w=(I%!4)*s:h=(I%!8)*t
      ENDPROC

where s and t are the horizontal and vertical scale factors respectively. If these are set to 1 (one) you will get the full size of the picture. Set to some other value you have the modified size returned, which is more useful for positioning the picture. You can call PROC_imgSize() immediately after loading the picture.

[DDRM]

Hi Kendall,

Can I suggest that if you provide functions that extend the role of a function provided in a library that you give them a name that reflects this, rather than overriding the library version? For example, you could call your function PROC_imgSizeEx (as many Windows systems have extended versions that look like this). Then people reading your code are less likely to be confused about what is going on (for example, the extra parameters).

Best wishes,

D

[KenDown]

It occurred to me to wonder whether there was any time penalty to using a procedure to find the picture dimensions rather than directly accessing the variables, so I modified four different versions of PRO_imgSize(), inserting a number in each name so that everything would be as similar as possible. What follows is not a complete program - if you want to play around you'll have to copy the rest of imglib and add some more bits and pieces, but it will give you an idea of what's going on.

Code: Select all

      PROC_imgInit(0)
      t%=FN_imgLoad(pic$)

      VDU4
      s=0.5:t=0.5
      TIME=0
      FORi%=1TO100000:w%=s*t%!4:h%=s*t%!8:NEXT
      PRINTTIME

      TIME=0
      FORi%=1TO100000:PROC_img2Size(t%,w%,h%):w%*=s:h%*=s:NEXT
      PRINTTIME

      TIME=0
      FORi%=1TO100000:PROC_img3Size(t%,w%,h%):w%*=s:h%*=s:NEXT
      PRINTTIME

      TIME=0
      FORi%=1TO100000:PROC_img1Size(t%,s,w%,h%):NEXT
      PRINTTIME

      TIME=0
      FORi%=1TO100000:PROC_img4Size(t%,s,t,w%,h%):NEXT
      PRINTTIME
      END
      :
      REM Richard's original procedure
      DEF PROC_img2Size(I%, RETURN W%, RETURN H%)
      W% = I%!4 : H% = I%!8
      ENDPROC
      :
      REM Richard's procedure with unnecessary spaces removed
      DEFPROC_img3Size(I%,RETURN W%,RETURN H%)
      W%=I%!4:H%=I%!8
      ENDPROC
      :
      REM My procedure with parameters
      DEFPROC_img1Size(I%,s,RETURN w,RETURN h)
      w=(I%!4)*s:h=(I%!8)*s
      ENDPROC
      :
      REM My procedure with parameters
      DEFPROC_img4Size(I%,s,t,RETURN w,RETURN h)
      w=(I%!4)*s:h=(I%!8)*t
      ENDPROC

The results on my laptop were 15, 32, 31, 56, 61; on my desktop it is 6, 11, 11, 15, 21. It is obvious that direct access is far and away the fastest, almost twise as fast as using a procedure and four times faster than passing two extra parameters to the procedure.

Of course the advantage to using the procedure is the standard interface - the user doesn't need to know the details. (For example, in SDL the width is discovered with W%=I%%!8 rather than the W%=i%!4 of BB4W.) Mind you, the difference in speed - even if you call the routine one hundred thousand times in succession - is miniscule given that those numbers are hundredths of a second! Still, if there are any speed demons out there who want the ultimate in performance ...

[DDRM]

Hi Kendall,

There will always be a significant penalty for a procedure call, since quite a lot of "state" (register values etc) needs to get saved somewhere, so it can be restored when you return from the array. If the procedure is doing something small, then the relative cost is quite high: but as you say, in absolute terms it is usually negligible unless it is repeated a lot, and the advantage in clarity and maintainability can make it worthwhile - especially as, in this case, it allows cross-platform compatibility.

On the other hand, one might argue that having a procedure to do something standard (like finding the size of an image), and then making "local changes" (such as adjusting by a local scale factor) might be clearer. Certainly, making the basic procedure slower and more complex to deal with a situation that may arise relatively rarely is unlikely to be a good choice: if you want to, to support a "local" need, then making a variant, with a different name, might be a good way to go.

Best wishes,

D