How to Scale Bitmap Faster

Why do you need to constantly rescale?
Is it possible for you to cache the scaled result and re-use it to save on scaling?
Scaling is always a heavy operation and those questions need answer first.

Then, onto making it faster...

1. Don't use TBitmapUtils,
It is very slow, because you will do a lot of unnecessary pixel conversions, and also a lot of unnecessary heap locking.

2. Generally, avoid any symbian draw calls
Unfortunately, high performance graphics programming is not symbians strong side.

3. Go low level
Use LockHeap, DataAddress and UnlockHeap to get raw access to the pixel buffer in memory.
This will need more knowledge on pixel formats, and some skill in modifying buffers efficiently.
The first is available on this forum by searching (or ask me) and the second is available in lots of example code out there, look for games and "democoder" examples from the 90s.

4. Optimize
For example, try avoid multiplications in your inner loops, calculate scanline offsets outside it (eg: y*data_stride)
Your algoritm looks pretty good though on the first look, though I don't have time to analyse it in detail

I think your main stumblestone might be pixel conversions going on inside TBitmapUtils when you read out and write back pixels. If the color depth is the same on dst and src, this is ofcourse unnecessary, but TBitmapUtils can't know this by its design.

In that case, If I were you, I'd take a look at some DDA zooming routines, and zoom directly to the screen.
You can even kick in rotation in it with almost no extra overhead.

In a DDA you only have add:s in your inner loop, you calculate all deltas outside it, so it is almost as fast as a straight blit (except that you will always trash the cache when you start rotating, decreasing performance because of this)

I wouldn't be suprised if you could get it faster then the (non-scaling) symbian CFbsBitGc:BitBlt if you make sure to match color formats on src and dst

I would say using openGL is even better
Specially if the image is not changeing.

Then you should be able to add some bilinear filtering too, without losing too much frame rate, increasing the image quality a lot.

Though, very few devices have real HW support still, most just use Hybrids SW OpenGL that S60 has licensed.
Hybrids engine has very good performance for being a SW only implementation, but its not sure it will be faster for this specific usecase.

Its ofcourse possible to add bilinear filtering to a software DDA routine too, but it slows it down with a factor of at least 10 times.

And it don't add that much quality as long as you are constantly moving the image, then you hide a lot of the aliasing, at least if you calculate your roundings right

bi-linear is mostly needed if you are going to scale an image and show it in that size for an extended time. (and then you can pre-calc it and redisplay it)