saveFrame trips ClassCastException on Raspberry Pi

[markstock]

This is an issue I raised on the Processing forum recently: http://forum.processing.org/topic/saveframe-trips-classcastexception-on-raspberry-pi

I am running Processing 2.0b8 under raspbian on a Raspberry Pi. The bad codes all use the Java runtime, and Java2D graphics. I taught a workshop to some middle-schoolers on using Processing to learn math and programming via algorithmic art.

Problem summary: All calls to loadPixels() bomb on a ClassCastException error:

Exception in thread "Animation Thread" java.lang.ClassCastException: [I cannot be cast to [S
at sun.awt.image.ShortInterleavedRaster.getDataElements(ShortInterleavedRaster.java:293)
at processing.core.PGraphicsJava2D.loadPixels(PGraphicsJava2D.java:2308)
at processing.core.PImage.save(PImage.java:3209)
at processing.core.PApplet.saveFrame(PApplet.java:4063)
at vortex_advanced.keyPressed(vortex_advanced.java:95)
at processing.core.PApplet.keyPressed(PApplet.java:3339)
at processing.core.PApplet.handleKeyEvent(PApplet.java:3157)
at processing.core.PApplet.dequeueEvents(PApplet.java:2606)
at processing.core.PApplet.handleDraw(PApplet.java:2277)
at processing.core.PGraphicsJava2D.requestDraw(PGraphicsJava2D.java:243)
at processing.core.PApplet.run(PApplet.java:2140)
at java.lang.Thread.run(Thread.java:722)

[benfry]

We don't have any support for devices that don't give us a 4-byte integer buffer of pixels.

To fix this, someone would need to implement it in PGraphicsJava2D. Basically anywhere that there's a getRaster() call in PGraphicsJava2D, there would need to be a temporary int-based buffer (most likely a BufferedImage of type ARGB) that things were copied into so that they could be manipulated in the way that Processing expects them.

[benfry]

This will affect saveFrame(), loadPixels(), get(), set(), filter(), etc... anything that talks to pixels directly.

[markstock]

RPi doesn't pass a 4-byte integer for a pixel color? That's a bummer. I'm going to look at my config.txt, maybe framebuffer_depth (?), to see if I was using/can use a 32bpp format. (http://elinux.org/RPi_config.txt)

Thanks for looking into it, though, and thanks for continuing to contribute. You made a tool that lets kids experience the same joy for programming and experimentation that I had on that TI-99/4A. I owe you at least a beer.

[chrisgagne]

I can confirm that adding the following to /boot/confirm.txt resolved this issue for me:

framebuffer_depth=32
framebuffer_ignore_alpha=1

I hope this helps someone...

(fixed typo, thanks janmeier)

[benfry]

Is there any way we can control that from inside Processing (or at least from the startup script)?

The RPi project is obviously a kindred spirit and we'd love to have better support...

[chrisgagne]

I have no idea... I just took markstock's lead and followed it through. :)

[janmeier]

I got it working using

framebuffer_depth=32
framebuffer_ignore_alpha=1

Using a framebuffer depth of 32 instead of 1 of. The depth is the number of bits per pixel, so a value of 1 doesn't really make sense

I'm pretty sure those settings cannot be controlled from inside processing, since changing them requires a reboot

[benfry]

@gohai reports that he cannot reproduce this with stock rpi and the current source.

Can others please confirm?

[benfry]

Seems like this is no longer an issue; closing.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.