Realloc the size of an Image object, possible?

#1

Hi, i’m making a program to display an image buffer on a window, the image buffer can be reallocated during the execution of the program when the user resizes the window.
The function i’m using to map the image is:

Component::paint() { g.drawImage(image......);

To allow the reallication of an image object i’ve created a class

class FrameBufferWrapper: public Image { ... };

In that class I have a function to reallocate the image buffer

[code]unsigned char* FrameBufferWrapper::reallocBuffer(unsigned width, unsigned height) {
imageData = (uint8*)realloc((uint8*)imageData,
width * height * bytes_per_pixel);

imageWidth = width;      // Problem here, const member
imageHeight = height;    // Problem here, const member
pixelStride = bytes_per_pixel;
lineStride = width * height * pixelStride; 

return (unsigned char*)imageData;

}[/code]

The problem is the imageWidth and imageHeight members of the image class that are const and can’t be modified. A solution could be the creation of a new Image object at each time the user resize the window, but it’s more expensive than a simple realloc call !

So how can I use an Image and modify it’s dimensions dynamically ? Also, I need to have an access to the data to use that image with the AGG library, is the Image solution the good one ? Are theire other functions to map pixels data one a window without allocate an Image object ?

Thanks.

Bouba

PS: Sorry for my english, I’m french :wink:

#2

Just create a new image - the cost of allocating an image is microscopic compared to actually doing anything with it. And when a component gets resized, there’s probably hundreds of other objects being created and destroyed - creating one more won’t make any noticable difference!

It’s easy to get access to the image data - didn’t you spot the lockPixelDataReadWrite() functions?

#3

Ok, thanks, i’ve read the description of the lockPixel… functions (perhaps the could be useful for me in the future).
But, even if the cost of an image creation is microscopic i’m managing a frame buffer with the AGG library. So each time the scene needs to be redrawn i will need to create an image object (ok, cheap), and copy each pixel of the AGG frame buffer inside the Image one, it could be very expensive !!! The ideal solution would be the possibility to directly use my AGG frame buffer in a mapping function of the Graphics class or use an Image frame buffer inside my AGG functions (not possible if I need to recreate an image object each time redrawing the scene is necessary).
So what could be the convenient solution to this problem ?

#4

If agg and juce store their images in different formats, then you’re going to have to copy and convert it no matter what happens. But if the data is the same internally, can’t you let the juce image create and manage the data, and tell agg to draw onto that data?

#5

Ok, as you said in the previous message, I tried using Juce to create and manage the frame buffer, and draw onto it with AGG, it works correctly!
But there’s something strange, In Juce the image format is Image::RGB, but when i’m using that buffer with an AGG object (Pixel Format Renderer, pixfmt_rgb24 that use an RGB format) witch use the same format it seems that the format isn’t RGB but BGR (red is blue, blue is red). Perhaps the documentation makes an abstraction of this pixel format detail and indicates only that there is the 3 color component (not precising there order) ?

In any case it’s not a problem now, i’m using a pixfmt_bgr24 AGG Pixel Format Renderer and it works, thank you for those resposnes !

Bouba

#6

I thought that agg was pretty flexible about the byte ordering that it can use? There’s probably an option in there to make it render to BGR.

#7

Yes, i’m using this options, AGG support a lot of different pixel formats, ARGB, BGRA, ABGR, BGR, RGB, … (more that necessary !!!) . So i’m rendering the scene in BGR, it works well. In a previous message you notice that you plan to use Cairo for rendering, have you take into account the AGG solution (I think it’s quicker than Cairo for the moment) ?

Thanks.

Bouba

#8

Well someone did some benchmarks recently and found that juce was quicker than both agg and cairo, so not much point in using someone else’s library to slow it all down!

The only changes I think might be worth doing in the future would be something that can use hardware acceleration where it’s available, probably via opengl.

#9

Ok, perhaps it was me ? I send you a mail why my last results that are more accurate. Sorry, it’s in french :slight_smile:

#10

ah yes, that was you!

#11