Optimizing the speed of a pixel processing algorithm

Just a thought. Did you try using the native scaling on the picture and its mask independently? Also, have you tried examining the values of the output from your ScalePicture vs. the native code, and where the differences are? It might be helpful to know where the native code is falling short, and perhaps provide a shortcut to “fixing” it.

(To be honest, I’d try it here, but it’s bit of a production to fire up Parallels and I’d rather avoid it, at least for tonight.)

If I cannot get suitable results OpenGL will be my last resort… but I’d first like to exhaust all other possiblities. I’d like to have a basic scaling method that is easy to use and doesn’t require all the complexities of setting up an OpenGL environment.

I’ve been experimenting with MemoryBlocks the whole of last night, but are yet to find a way to increase to speed of the algorithm. So I am starting to also think that RGBSurface aint all that bad. Will still hammer at it for a while though, before giving up on caching the pixels in MemoryBlocks.

Using the native scaling and then scaling the mask independently just might be what I was looking for to get the quality and speed I need. The native scaling is currently super fast, so perhaps this might just be the answer.

Will get back to you on this one.

Thanks for all the advice guys. The speed of the algorithm has already improved a lot because of it.

If there is any other ideas, please send 'em through.

I’ll make sure to post the final scaling routine here, so that everyone can benefit from it.

Just for everyone’s interest, Jim gave a great example of using the GDI+ API to scale images with in this thread…

https://forum.xojo.com/9403-scale-quality-of-canvas-control/34#p67806

We have a winner.

The declares that Jim suggested in the other thread, not only outperforms the custom scaling routine by huge margins, but the quality is also perfect :slight_smile:

The scaling time in my tests went down from 14ms to 3ms with a small picture, and from 37ms to 22ms with a larger picture. I won’t be pursuing alternative solutions anymore, since this was exactly the speed and quality I was looking for.

Once again, than you for everyone’s contributions.

With out further ado, the final platform-independent routine that delivered the best results:

Function ScalePicture(p as picture, width as integer, height as Integer) As picture
  Dim res as new picture(width,height)
  
  #if TargetWin32 then
    
    // tell GDI+ to do quality scaling
    
    Soft Declare Function GdipSetInterpolationMode Lib "Gdiplus" (graphics as int32, Mode as int32) As int32
    Call GdipSetInterpolationMode(res.graphics.Handle(Graphics.HandleTypeGDIPlusGraphics), 8)
    
  #endif
  
  res.Graphics.DrawPicture(p, 0, 0, width, height, 0, 0, p.width, p.height)
  
  return res
  
End Function

What would be the ramifications of Xojo setting the interpolation mode for us when we tick Use GDI+ ? Shouldn’t the default be best quality? I mean, you explicitly turned on GDI+. If you want higher speed, you can set it to use lower quality/faster interpolation.

Thoughts? What does Xojo set it to now?

I’m thinking it should be best quality by default, and then be left to the programmer to reduce the quality when they are designing speed critical applications. Not sure what Xojo is using at the moment.

Added the suggestion to <https://xojo.com/issue/32371>.

By default a program should look its best, and quality should only be compromised as a last resort IMO.