Mouse events + repaint has too much latency

I am trying to create interactive animations with the mouse, but it is quite slow even without any other process in the application.

The way I do it is very simple, I overriding mouseDrag, update the position, and call repaint. In the paint method draw the square in the new position. You can see the lag with respect to the mouse pointer. Plus an ugly flickering

Animation

Maybe I should activate something or do it in another way?

have you tried compiling this in release mode yet? i usually only get lags in debug and with a window size bigger than half my screen

that’s. It seems that the background drawing task has too much processing in debug mode. It is best to limit the cleaning area.

yeah that’s true as well. also you can often reduce paint calls by setting components setBufferedToImage(true). this is useful if a component draws something really complicated (more than a rectangle) and has an overlapping component on top of it that also needs a repaint. now the overlapping components asks the one below for its image at that place and since this image was buffered it doesn’t have to be calculated again. this will come in handy once you try to make your animation stuff more fancy or do stuff with text

1 Like

Could you post a minimum project/example to show your problem?

Mrugalla identified the problem. Mouse events are fine. It seems that the graphics are very dependent on the processor, even to clean the window with fillRect, so in debug mode the effect was excessively noticeable.

Well, I had already finished this post, but what I have discovered is incredible

I have thought that maybe I could combine OpenGL to clean the window and other heavy tasks.

What has been my surprise, that by the mere fact of adding the opengl render to the component, the drawing of the Gui has become super fast. I’ve actually tried to clean the component in a loop 500 times maintaining a smooth animation, or 30 times with g.drawImage

I have not used any OpenGL, only what is necessary to activate it. It also works on the main component, that is, it is not necessary to do it on the drawing component. In case it helps someone, it is very simple, just Add OpenGLRenderer to the component, and overriding newOpenGLContextCreated, openGLContextClosing, and renderOpenGL, necessary because they are pure. and initialize the OpenGLContext like this:

    openGLContext.setOpenGLVersionRequired(juce::OpenGLContext::OpenGLVersion::openGL3_2);
    openGLContext.setRenderer(this);
    openGLContext.attachTo(*this);

and the magic appears.

I have no idea what’s going on, but I think this should be able to be activated in some transparent way for the programmer.

2 Likes

Well yeah, that’s expected: OpenGL renders the UI on a separate thread instead of the main thread. But beware that it comes with its own set of issues. Search for OpenGL on the forum.

1 Like

FWIW, Audacity (wxWidgets) has negligible mouse latency when run in the Local Windows Debugger, as compared to a simple 1-component JUCE GUI app. Both tested in a full-screen, UHD size. So this must not be related to the IDE (VS2019) and/or debug mode.