I’ve an algorithm where I process a transform on a (memory) Image, and then draw this image to the graphics object.
Up to now, I wasn’t fighting too much about speed, but I’ve added visual feedback based on user mouse movement. I’ve added timing information on my transform algorithm (it takes 30 to 60 milliseconds, 40ms avg).
In the end of the transform, I have a repaint() call.
However, it is clear that I’m not seeing 25 frames per second. I’ve tried to change setBufferedToImage (but I haven’t really seen a difference) to false (as I’m just drawing my image), but it is clear that the paint routine is not called like it should (it is always delayed)
Is there a way I could force a repaint asyncronously (isn’t what repaint() is supposed to do ?) ?
Well no - the OS chooses when to ask the window to repaint itself. Repaint() will tell it that it should do so as soon as poss, but that’s all you can do to influence it.
Are you actually doing your transform in the paint() routine? If not, are you sure you’re not doing it more often than you need to?
setBufferedToImage() is irrelevent here, and will actually slow things down - it’s intended for caching components that draw slowly and rarely change their content.
I’m not doing the transform in the paint routine (I’m buffering it to a memory image). And yes, I’m doing it more often than I should, and that’s the point of my question.
After I transform my image to the memory image, I’m calling repaint() that, if I understand correctly, should call InvalidateRect() which, in turns, should send a WM_PAINT message, and then (through Juce), call paint().
What I’m experiencing is that I’m receiving WM_MOUSEMOVE messages more often than WM_PAINT (and WM_MOUSEMOVE messages are being intercepted by mouseDrag() which call the transform() again).
I don’t understand why this happens.
If it is due to message jam in the queue I shouldn’t get WM_MOUSEMOVE more ofter than WM_PAINT. So I guess it is due to something else, maybe a delay/priority in the message processing loop ?
Does each WM_PAINT message end with a paint() call ?
I’ve somehow enhanced the behaviour by using a “isPainted” flag to exit mouseDrag message if it is not painted yet, but I’m quite sure it should work without…
mouse moves are unrelated to paint events, and you’ll probably get many more mouse events - so if you do your transform every time there’s a mouse move, not only will a lot of these be wasted, but it’ll actually stop the paint events getting through.
The best plan is to do all the rendering in the paint routine, so it only ever happens when it’s actually going to hit the screen. Your mouse move should just set some kind of flags and call repaint().
However, I think the documentation should state that repaint() is just an advice, and is not ensured to happen when called, but whenever the OS wants it (which can happen after mouse moves, for example).
I understand “asyncronous” as immediate, which should read “delayed” or “queued” instead.
‘synchronous’ means “it happens at the same (syn) time (chronos)” which is impossible with current CPU (which are sequential)
I’ve understood, (and I was wrong), that synchronous would means will be processed next (in the message send/receive process behaviour of all OS), ie right after other queued processes
I’ve understood “asynchronous” like it would delay everything else to execute ASAP, ie not in the synchronous way of processing (which is not the case).
BTW, it is what I would expect from a repaint() call, to repaint when I call it, not when OS wants it to.
Sounds great, but in practice that approach doesn’t work at all. Imagine if each mouse-event forces an immediate repaint, during which several more mouse-events get queued… Bang.
Well, the gui’s are event driven. *nix still uses interrupts for an event drivin like thing. If you are dealing with Juce though, you are probably using the gui.
I am actually working on a project that requires minimum 30fps for the OpenGL components we’ll be using.
I’ve been working with the technology all of seven hours so I am not up to speed on everything, but my assumption was that OpenGL support meant I could create a window that would support animation with whatever capabilities my Video Card was capable of.
[quote=“rbottoms”]I am actually working on a project that requires minimum 30fps for the OpenGL components we’ll be using.
I’ve been working with the technology all of seven hours so I am not up to speed on everything, but my assumption was that OpenGL support meant I could create a window that would support animation with whatever capabilities my Video Card was capable of.[/quote]
That’s right - it lets you embed an opengl window in a juce window, and you can draw onto it in any way you like, avoiding the juce paint mechanism altogether if that’s what you need to do.
