Comments on: Handling red Java console errors

By: Tank Yew

Tank Yew — Mon, 03 Jul 2017 11:11:14 +0000

I get these red java messages on startup but they seem benign. The main problem (for me) is that everytime I use plot or imagesc or any of the graphics UI (zoom, pan, etc.) the console dumps 100s of messages saying the same thing:

JavaSceneServerPeer problem: Couldn’t create JOGL canvas–using painters

It’s not in red and it doesn’t seem to affect anything except for rendering the console useless for conveying information (except for the above message, obviously!). Any ideas how to divert these messages to a log file instead of console?

By: Yair Altman

Yair Altman — Tue, 06 Dec 2016 14:04:48 +0000

@Schorsch – thanks. I corrected this typo in the text.

By: Schorsch

Schorsch — Tue, 06 Dec 2016 13:32:08 +0000

Minor note:
it should be

fprintf(' \b');

instead of

fprintf( '\b');

By: Yair Altman

Yair Altman — Fri, 01 Jul 2016 11:09:16 +0000

@Xiangrui – I’m glad I helped. I should have emphasized in the post text that not all suggested remedies work in all cases; in some cases some of them work and in other cases others work. There does not seem to be a general panacea to this issue. The main purpose of the article was to list the possible solutions in a single place, so that users like yourself could try them out and select those of them that work for each specific case. I’ve now added this clarification to the main text.

By: Xiangrui Li

Xiangrui Li — Fri, 01 Jul 2016 01:00:25 +0000

Wow, this post is just in time for me! I am experiencing the exact problem recently since I start to use DefaultListModel. I figured out drawnow reduces the chance of red output, but it still happens occasionally.I just tried the suggested tricks one by one. It seems fprintf(' \b') is not very effective. pause+drawnow works well, and javaObjectEDT trick alone works well too. Anyway I am using both for now.Thanks, Yair.-Xiangrui

By: Malcolm Lidierth

Malcolm Lidierth — Thu, 30 Jun 2016 05:40:45 +0000

A couple of general comments:

pause(0.05); drawnow;  % this never hurt anyone!

Flushing the event queue unnecessarily can hurt when large data sets are displayed. Repaints are handled on the EDT, and managed by a RepaintManager that runs on another thread. The RepaintManager seeks to collapse multiple paint requests into a single, or fewer requests (so, if a request to update a specific screen region is called repeatedly, the RepaintManager can paint that region just once putting the end result on the screen). Flushing the queue can potentially disrupt that optimisation.

For Swing components, calling the revalidate() method will often be more efficient – and may be what

fprintf(' \b')

achieves. This marks a component as “dirty” and schedules a layout for its parent. It also marks it to be repainted next time an ancestor is repainted – which can be achieved with a direct call to the repaint() method. Both revalidate and repaint methods are thread-safe for JComponents.

In MATLAB, there is still an issue of how that relates to TMW’s graphics pipeline. A final pause/drawnow may be needed.
—

For the unwanted errors: I wonder if those are being written direct to the console or via a logger. MATLAB ships, or once shipped, with log4J. If that is using a console logger for output, it might be possible to replace it and install a custom logger or turn it off.