Graphics context

I’m missing something important here about JUCE and its Graphics object, but please humour me. I have a graphics object that is passed an image

image(Image::RGB, 300, 400, true)

I want to periodically make calls to the graphic object to draw things to that image, which should then get updated in my paint routine:

void CabbageGraphics::paint (Graphics& g)
    g.drawImageAt(image, 0, 0);

So I periodically make calls in simple timer:

void CabbageGraphics::timerCallback()
    myGc.fillEllipse(x+=10, 10, 10, 10);

It successfully draws the first time the timer callback is triggered, but only once. Is there a way to do what I want without having to keep passing my image to a new Graphics object for drawing?

The Graphics context is not meant to be kept… create it on the stack and let go, when your scope finishes. It needs that to flush successfully when painting is done…

You can keep the image though

1 Like

Which is always how I’ve used it in the past, hence I’ve never had the issue before. I only wanted to do it this way so that I could keep track of the context’s colour, stroke, etc., between each successive calls.

[Edit] thanks for the quick reply btw!

1 Like

@daniel, do you know if the same applies to the OpenGLContext class? Speaking of context, let me outline what I’m trying to do. I’m basically trying to pass a graphics context to a dll, in which all the drawing should take place. While I can successfully access the context in my dll, I’m finding it tricky to draw directly to the OpenGLContext. I’ve been able to successfully draw to an image in my dll, which my host was able to pick up, but it was terribly slow. I’m not sure this will be much faster, but do you think it should work, in theory at least?

I avoided using OpenGL specific functions so far, what I did went through the juce::Graphics context.
I hoped to send you a link to a save method, but had to realise, that the ScopedSaveState just uses an internal stack (similar to the matrix stack in OpenGL), so you can’t get a struct of the state, that you could reapply.

However, I would be surprised if setting the states would be the bottleneck, but that is just a gut feeling that I cannot back up with anything…

Sorry and good luck

EDIT: I just remembered, that there is a specific ImageType, that is an OpenGLFrameBuffer. So drawing on that should avoid round tripping through the CPU’s memory: OpenGLImageType
Maybe that is a remedy…

1 Like

Thanks, that might just do the trick :wink: