Need some extra functionality for optimizing Image drawing

General JUCE discussion
1

Unfortunately there is no straightforward way to construct an Image of type RGB whose pixelStride matches the pixelStride of backbuffers used to draw the ComponentPeer. This would be a useful function because it would improve the performance of Graphics::drawImageAt

The good news is that this is quite a straightforward change, and I’ve outlined the details here:

  1. Add a function static Image::getNativeRGBPixelStride which returns 3 or 4 depending on the video card. This would be platform specific. On Windows we would move the code out of WindowsBitmapImage and into this function.

  2. Add or modify SoftwarePixelData constructor to take a pixelStride parameter.

  3. Change all instances NativeImageType::create to create the SoftwarePixelData with a pixelStride from the return value of getNativeRGBPixelStride.

  4. Optionally add a new function static Image::createNativeRGBImage which returns an empty RGB image using NativeImageType and the specified width, height, and clearContents flag.

#4 is needed because there is no handy Image constructor that takes a pixelStride parameter, and also for convenience - anyone who wants to optimize their image drawing just needs to switch over to calling this new function instead of using operator new directly.

2

It might also be helpful to provide this function:

Image Graphics::createCompatibleRGBImage (int width, int height, bool clearContents);

This will create an RGB image whose pixelStride is based on the pixelStride of the RGB image that the Graphics is drawing into. The default implementation can just call the Image constructor (i.e. don’t care), while the software renderer can perform an actual check on the underlying image and if it’s RGB, re-use the pixelStride.

This way, it will be possible to create images that will always get the best performance for a given Graphics context.

3

This all sounds pretty sensible to me.

4

Yep, I figured that. Just wondering though whats the difference between NativeImageType and WindowsBitmapImage? I would think that NativeImageType created an HBITMAP or DibSection on windows. Ditto for android and other platforms.

5

NativeImageType is just a wrapper around some unspecified platform-specific format. WindowsBitmapImage includes some HBITMAP stuff, but since that’s only needed in one place in the code, I don’t think there’d be much point in adding all the extra HBITMAP fluff to every image created.