Bad refresh rate on Linux when not moving mouse

Processing
1

Hi there,

having a typical Java2D issue on Linux where window is not instantly repainted unless mouse is moved. In my own Scala code I usually try to get around it by calling component.toolkit.sync(). Has nobody experienced this problem yet? Using latest 4.0b7 on Debian 11. Is there a way to get the repainting to work smoothly even in the absence of mouse movement?

(the effect is better discerned when run live than in the screencast, but should still be visible)

I tried adding java.awt.Toolkit.getDefaultToolkit().sync(); in draw(), but it has no effect, probably because it would have to be called precisely outside the repaint methods.

2

Adding this to setup() seems to help:

  java.util.Timer t = new java.util.Timer();
  final java.awt.Toolkit tk = java.awt.Toolkit.getDefaultToolkit();
  java.util.TimerTask tt = new java.util.TimerTask() {
    public void run() {
      tk.sync();
    }
  };
  t.scheduleAtFixedRate(tt, 20, 20);
3

I make a lot of animations using Processing on Linux Mint on a desktop PC using nVidia’s proprietary drivers and have never noticed a jerky framerate. Or, I should say, any jerkiness I noticed I attributed either to complex computations to generate the images or to other processes like Chrome thrashing CPU or memory.

I’m traveling at the moment, so I can’t test your example of a spiraling image, but I’ve definitely made simulations of particle swarms flying around at 60 fps that look perfectly fluid without any mouse motion whether I’m using the Java2D, P2D, or P3D renderers.

What video drivers on what graphics hardware are you using? Do you get a similar effect from both the default renderer and P2D or P3D? How about outside of Processing, such as with p5js in your browser or animations on shadertoy?

1 Like
4

Not sure, this is what is printed:

$ sudo lshw -c video
  *-display                 
       description: VGA compatible controller
       product: GA104
       vendor: NVIDIA Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       logical name: /dev/fb0
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress vga_controller cap_list fb
       configuration: depth=32 latency=0 mode=1920x1080 visual=truecolor xres=1920 yres=1080
       resources: iomemory:600-5ff iomemory:620-61f memory:6d000000-6dffffff memory:6000000000-61ffffffff memory:6200000000-6201ffffff ioport:4000(size=128) memory:6e080000-6e0fffff
  *-display
       description: VGA compatible controller
       product: Intel Corporation
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 01
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: iomemory:620-61f iomemory:400-3ff irq:167 memory:624c000000-624cffffff memory:4000000000-400fffffff ioport:5000(size=64) memory:c0000-dffff memory:4010000000-4016ffffff memory:4020000000-40ffffffff

My guess is that the Intel graphics is in use and not the Nvidia (and no proprietary drivers loaded AFAICS). So might be an Intel driver related issue?

Using P2D or P3D solves the bad rate, but obviously the code is no longer the same (the shape operations do not produce the same results, for example). I’ll have to check if this all holds for the Raspberry Pi 4B as well, which is the target machine.