Processing Forum

is it possible to run fullscreen from IDE?

[2 Replies]
- 15-Mar-2013 11:34 PM
- Forum: Programming Questions
without exporting as an application?

if not, i could probably write up a tool to do that. someday...

NoClassDefFoundError for javax.media.opengl.GLException when exporting application from Eclipse

[0 Replies]
- 07-Mar-2013 11:52 AM
- Forum: Integration and Hardware
I was having trouble with my exported application tossing up a NoClassDefFoundError for javax.media.opengl.GLException from my size() call. Turns out that this was because my Info.plist file was pointing at "jogl.all.jar", but the file has been renamed to "jogl-all.jar" in versions of Processing after 2.0 alpha 6.

Posting here in case I can save anyone *else* 3-4 hours

Updated in this post describing how to export an application from Eclipse using the now-quite-broken-but-still-patchable Proclipsing as well.

custom fonts on android?

[1 Reply]
- 14-Feb-2013 05:26 PM
- Forum: Android Processing
I put my custom fonts in the 'data' folder, and implement them with createFont(), using the name as listed by PFont.list().
This sketch works correctly in Java mode.

When I run on the Android emulator, I get a warning: "Inefficient font rendering: use createFont() with a TTF/OTF instead of loadFont(); however, the fonts render correctly.

When run on my device, I get the same warning, but the fonts fallback to some Android system font.

I'm on a Nexus 7.

What am I doing wrong? Seems like the fonts aren't getting copied to the device. println(PFont.list()) shows only Android system fonts, though I think that's to be expected, hence using createFont() instead of loadFont().

EDIT: I tested loading and drawing an image in the 'data' folder, and that works fine, so I think it's less likely that the fonts aren't getting copied than that they're not getting used. Maybe my .otf files are not good enough for Android?

Blending very large images: performance, memory

[1 Reply]
- 16-Jan-2013 04:59 PM
- Forum: Core Library Questions
I need to alpha blend 2700x1600 images at runtime. Not totally surprisingly, I'm having problems keeping my framerate up. I've tried doing the blending on an offscreen buffer, but that hasn't seemed to help much if any. Are there any general strategies for working with images this large that might apply to this situation? Something to leverage the graphics card as much as possible, perhaps?

I'm also having a bit of trouble managing memory; each of these images uncompressed is ~17MB (2700x1600x4 bytes), and there are a total of ~60 images I'll be blending (not all simultaneously!). I have strategies in mind for the memory issue that are outside the scope of this question, but I include it here in case there is a clever way to balance memory usage between the computer's memory and the graphics card.

Based on my digs into the source, it does seem that Processing (PGraphicsOpenGL specifically) is using JOGL internally for PApplet.image(), so that optimization at least is already happening.

Advice in raw JOGL is not as nice as Processing code, but I can probably thrash my way through it if there's a JOGL route.

Basic strategy (very simplified code) as of right now is:
1. PImage a = loadImage("imageA.png");
2. PImage b = loadImage("imageB.png");
3. PGraphics buffer = createGraphics(width, height, OPENGL);
5. void draw () {
6. buffer.beginDraw();
7. buffer.tint(255, 200);
8. buffer.image(a, 0, 0);
9. buffer.tint(255, 100);
10. buffer.image(b, 0, 0);
11. buffer.endDraw();
12. image(buffer, 0, 0);
13. }

splitting screen across multiple displays

[11 Replies]
- 29-Oct-2012 06:29 PM
- Forum: Programming Questions
i have a large application that i'd like to display across 3 displays. each display is 900x1600, for a total sketch size of 2700x1600.

i'm having trouble with the hardware routes i've tried, so i'm falling back to a software route, but my framerate is suffering. my strategy currently is to draw into a PGraphics buffer, then PImage.copy three rectangles from the buffer into areas that correspond to the three-monitor layout within a PImage. and then draw that PImage to the screen.

like so:
1. PGraphics fbo;
2. PImage tex;
3. // setup etc...
4. fbo = createGraphics(w, h);
5. tex = createImage(width, height, RGB);
6. // draw into fbo...
7. tex.copy(fbo, 0, 0, 900, 1600, 0, 0, 900, 1600);
8. tex.copy(fbo, 900, 0, 900, 1600, 0, 1600, 900, 1600);
9. tex.copy(fbo, 1800, 0, 900, 1600, 0, 3200, 900, 1600);
10. p.image(tex, 0, 0);
the specific numbers here are probably irrelevant, they're artifacts of the way i have my three screens setup (for reasons i won't go into now, i'm working with a screen setup that wants a 900x4800 (3x 900x1600) application). the tex.copy() lines are the real fps killers; if i just draw fbo straight to the screen, my framerate jumps from the ~6-7fps i'm getting now up to ~24fps.

i'm mostly interested in hearing if there are better / more performant ways to split a large buffer into three smaller sections. i'm also interested in hearing if anyone else has gone across three displays and if so, how. i can fill in more details on hardware if the thread moves in that direction.

recover from PortInUseException

[0 Replies]
- 23-Jul-2012 05:23 PM
- Forum: Core Library Questions
i'm having a problem with PortInUseException sometimes being thrown by Serial when i run an application using the Serial lib on startup.

my workaround is to attempt repeatedly to initialize the serial object if the initialization fails. basically:
1. public void initSerial () {
2. try {
3. serial = new Serial(this, Serial.list()[0], BAUD_RATE);
4. serialInited = true;
5. } catch (RuntimeException e) {
6. if (e.getMessage().contains("<init>")) {
7. System.out.println("port in use, trying again later...");
8. serialInited = false;
9. Timeout retrySerialTimeout = new Timeout(this, "initSerial", 5000);
10. }
11. }
12. }
that Timeout class is my own class; you can use any method you want to re-try Serial initialization (e.g. a frame counter in draw()). the serialInited boolean is a flag i check in draw() -- if !serialInited, i just draw a big red X. once serialInited = true, i know Serial was successfully inited, so i continue on with my program.

just a little tidbit in case it helps someone else down the road.

turning smooth on and off (opengl)

[2 Replies]

13-Jul-2012 01:36 PM
Forum: Core Library Questions

so now that opengl smoothing is working for me (thanks andres!), i'm wondering about how best to use it...

i have an application with, basically, a particle system and a GUI. the particle system only performs well with smoothing turned off; the GUI wants smoothing on to do things like draw circles and smooth animation.

however, turning smooth on and off every frame to render the particles and GUI alternately is not an option. from PGraphicsOpenGL:

"The smooth/noSmooth functions are being called too often.

This results in screen flickering, so they will be disabled

for the rest of the sketch's execution."

for the circles and diagonals in the GUI that need smoothing, i could conceivably draw to a buffer and blit that to the screen. however, some of the GUI content is animated, so i need to update it every screen.

...as i'm writing this, i think i'm realizing the answer -- create two buffers, each with their own renderers, one for the particle system and one for the GUI. particle system's renderer has smoothing always turned off; GUI's renderer has smoothing always turned on.

i'll give that a try when i have time and report back; in the meantime, if anyone has insight on this please share.

smooth (antialiased) lines in OpenGL

[15 Replies]
- 10-Jul-2012 05:49 PM
- Forum: Core Library Questions
i feel like i've asked this question before, but not sure i ever got an answer and scouring the forums isn't getting me anywhere...

i'd like a nice antialiased ellipse in GL. i'm using 2.0a6. this code:
2. void setup () {
3. size(200, 200, OPENGL);
4. }
6. void draw () {
7. background(0);
9. ellipseMode(CENTER);
10. stroke(255);
11. noFill();
12. ellipse(0.5*width, 0.5*height, 100, 100);
13. }
yields this image:

adding smooth() to setup() or to draw() has no effect. the aliasing is even more apparent when the strokeWidth() increases...

glitchy text in opengl

[2 Replies]
- 10-Jul-2012 10:45 AM
- Forum: Core Library Questions
i'm drawing some text over some other stuff (a particle system, drawing lots of rects with low alpha), and it's occasionally a little glitchy -- chunks of the text will briefly flash on and off.

pretty sure this has something to do with drawing multiple things at the same Z in opengl, but not sure how to get around it. there was textMode(SCREEN), but that's deprecated in processing 2.0 (i'm currently using alpha 6). any other suggestions?

haven't tried drawing the text at a slightly higher Z yet; that seems a little hacky but worth a shot i guess.

how to find screen coordinates of sketch?

[2 Replies]
- 10-Jul-2012 10:20 AM
- Forum: Programming Questions
i need the upper-left corner of my sketch in screen (OS) coordinates. i've tried using frame.getInsets() but i found that PApplet's frame is a local variable inside main(), and the public Frame frame in PApplet is never used (weird...).

any clues?

Proclipsing trouble, especially with OpenGL? Read this.

[1 Reply]
- 27-Jun-2012 02:40 PM
- Forum: Integration and Hardware
I'm a long time user of Proclipsing, and before that EclipseP5Exporter. Proclipsing is a super useful tool, and opens the gate for Processing users to an even more useful tool, namely Eclipse.

However, as time has gone on, I've run into more and more trouble exporting applications from Eclipse via Proclipsing. I finally hit a wall and had to haul my ass over it, so wanted to share with you what I learned in the process.

Note: I'm on OSX 10.6, so your mileage may vary on other platforms.

Where Proclipsing works just fine

When you're not using other libraries (including OpenGL, which is used by default from 2.0 alpha 6 forward), Proclipsing seems to work very well. It's when you have libraries involved that things start to get messy.

Where Proclipsing breaks

I've noticed that Proclipsing copies files into Eclipse.app when it first exports an application (after being installed). Within Eclipse.app > Contents > MacOS, Proclipsing creates a '/lib' folder, and dumps a bunch of files from...somewhere. I'm not sure where these files come from exactly, but they include OpenGL jars and natives. These files stashed in Eclipse.app are then copied to applications exported from Eclipse by Proclipsing. (Note: "natives" are files that connect java to the operating system for certain functionality like serial, video, and graphics card access, which is needed by OpenGL. These files are named *.jnilib for OSX, *.dll for Windows, and *.so for Linux.)

When you create new Proclipsing Projects in Eclipse and target new versions of Processing, Proclipsing will copy the jars from the libraries within the specified version of Processing into the /lib folder of your project. I've found that this generally works as intended. When it doesn't, you can often fix things up by editing your Project>Properties>Java Build Path, ensuring that required jars are on the build path and that the "Native library location" for each jar that uses natives is set to the path of those natives.

However, when exporting an application with libraries, specifically with OpenGL, it seems that Proclipsing copies the files it stored inside Eclipse.app into your application, regardless of what's inside your project's /lib folder.

How to fix it

I found my answers by poking around inside a simple OpenGL application exported from Processing 2.0a6 (which works), and comparing (via a free software called FileMerge) with the contents of a Proclipsing-exported application using 2.0a6 (which doesn't work). There are a couple of major differences to correct in the Proclipsing export to get it to run like the Processing export. To fix up your own Proclipsing exports, I suggest you export an application from Processing and cannibalize it.

1. Package the correct jars

Open up your Processing-exported OpenGL application via right-click>Show Package Contents (on OSX), and navigate to Contents/Resources/Java. You will see a jar with the name of your application (we'll call it MyProcessingExport.jar), and six other jars (as of v2.0a6). These jars are core.jar, gluegen-rt.jar, jogl.all.jar, opengl.jar, and two other platform-specific jars that contain GL natives (e.g. for OSX: gluegen-rt-natives-macosx-universal.jar and jogl-all-natives-macosx-universal.jar).

EDIT: for > 2.0a6, jogl.all.jar changed to jogl-all.jar. ARGH.

Open up your Proclipsing-exported OpenGL application the same way and navigate to the same /Java folder. You'll likely see a whole bunch of other files. Delete all of them except the jar with the name of your exported application (we'll call it MyProclipsingExport.jar).

Copy all of the jars from the Processing export *except* MyProcessingExport.jar into the /Java folder within your Proclipsing export.

2. Edit your info.plist file

The info.plist file in an OSX application tells OSX how to run an application. For Java applications, it includes information about the JVM to use, whether to use 32- or 64-bit mode, what command-line JVM options to use, and the class path to other jars. Info.plist is an xml file, and can be edited in any text editor.

Proclipsing forces the JVM to run in 32-bit mode to get around issues with "video and most other native libraries" (per a comment in the Proclipsing-generated info.plist file). I think this may be an outdated issue, and I've found that 2.0a6 OpenGL applications run twice as fast in 64-bit mode, so let's eliminate that restriction. Within <key>LSArchitecturePriority</key>, add <string>x86_64</string> to the list of JVM architectures. You can also eliminate PowerPC if you're not running on a very old machine. You should now have:
2. <key>LSArchitecturePriority</key>
3. <array>
4. <string>x86_64</string>
5. <string>i386</string>
6. </array>
You should also specify JVM 1.6, as that's now the preferred JVM for Processing applications. Proclipsing defaults to 1.5. Change the value below <key>JVMVersion</key> to 1.6*:
2. <key>JVMVersion</key>
3. <string>1.6*</string>
We specified the JVM architecture (32- or 64-bit mode) above, so delete the JVMArchs key and the array below it:
1. <key>JVMArchs</key>
2. <array>
3. <string>i386</string>
4. <string>ppc</string>
5. </array>
Finally, ensure your <key>ClassPath</key> only has the jars we placed inside the application. Simplest way to do this is to copy this <string> value from the info.plist in the Processing-exported application over the <string> value in the Proclipsing-exported application. We then have to ensure the line references the name of the Proclipsing-exported application jar (e.g. MyProclipsingExport.jar), not the jar export from Processing (e.g. MyProcessingExport.jar). You should have something like:
1. <key>ClassPath</key>
2. <string>$JAVAROOT/MyProclipsingExport.jar:$JAVAROOT/gluegen-rt-natives-macosx-universal.jar:$JAVAROOT/gluegen-rt.jar:$JAVAROOT/jogl-all-natives-macosx-universal.jar:$JAVAROOT/jogl.all.jar:$JAVAROOT/opengl.jar</string>
(Note that if you have other jars in your project, they should be referenced here as well.)

Run your fixed application

Double-click it. It should now run, and possibly twice as fast as before since it's now running in 64-bit mode. Yay!

If not (Boo...), open up Console.app (in Applications>Utilities) and see if you get any clues from there about missing classes or files. I've found that in some circumstances, Proclipsing does not package your /data folder into the exported application. Not sure why yet, but when this happens Console.app can help you see the failed file loads. The path at which a Java application starts looking for external resources (e.g. fonts, images, data or config files) is the path from which it is launched. For example, if your application is looking for a file at path "data/somefile.txt", in the case of a double-clickable application, your /data folder should be in the same folder as MyExportedApp.app.

Phew. That is a synopsis of a couple days of slogging through this stuff, and I've learned more than I reported here. So if you have questions or clarifications please post them and I'll try to help. Also, I'm sorry I don't have instructions for OSes other than OSX; I'm not sure how Java applications are bundled on other platforms. If you have tips, please add them as comments.

Finally, I understand that the Proclipsing team is not really supporting Proclipsing anymore because of the Processing Eclipse Plugin, a Processing-endorsed alternative to Proclipsing. Unfortunately, the Eclipse Plugin seems to be dead on the vine; the last edit was January 2011, and the bottom of that wiki page reads

While the UI for an export wizard is in place, it doesn't fully function. A partial export will take place, and log a bunch of messages to the console but nothing functional will have happened. For now, you'll have to use the PDE as an external editor.

I totally understand the Proclipsing team's decision to stop supporting a tool that must be updated every time Processing is updated -- it's hard work. If anyone out there wants to take up the mantle and fix these issues, I'm sure they'd welcome the assistance.

Hope this helps!

-Eric

exported application runs slower than in IDE

[6 Replies]
- 22-Jun-2012 01:05 PM
- Forum: Integration and Hardware
i have an OPENGL application that runs significantly slower when i export it to an application than it does when i run it in my IDE (Eclipse). it has a lot going on, including a high-count particle system rendered in GL, Unfolding maps, serial, and a few other libs.

i've noticed also that it runs a bit faster, though still not as fast as when run from Eclipse, when run via java -jar from the command line.

i haven't yet pinpointed the cause of the slowdown, thought i'd float the question here first.

one thing i have tried: exporting the SpaceJunk example in Examples...Libraries/opengl/form.

there is no noticeable performance difference between running it in the Processing IDE and running it as a full-screen application.

i'm on OSX 10.6.8, Processing 2.0a6, Eclipse 3.7.1.

haven't tried other versions of Processing yet, may be a renderer issue, though as i said i don't see this problem with the SpaceJunk example, also in 2.0a6.

communication between desktop (OSX/PC) and android

[2 Replies]
- 30-Jan-2012 04:46 PM
- Forum: Android Processing
i'm thinking about an application that communicates between a tablet and a PC. the PC would send arrays of URLs to the tablet; the tablet would load the URLs into a slideshow. a selection made on the tablet would then send a string back to the PC, which would filter its display based on that selection. there would be multiple tablets, each running the same software, associated with one PC.

so, in short: simple string communication between PC and devices.

how do i go about this? software-wise, are there libraries to accomplish this? example code? i'm really not even sure where to start. network-wise, would the devices just sit on the same LAN and communicate via UDP? hardware-wise, would this be a USB thing? bluetooth? wireless network?

any clues, links, snippets welcome. thanks!

proclipsing-exported applications fail with LSOpenURLsWithRole error (OSX 10.6)

[3 Replies]
- 28-Dec-2011 09:33 PM
- Forum: Integration and Hardware
i'm not sure what i changed, but for some reason all of my applications exported via proclipsing now fail to run. when opened from the command line, i see:

LSOpenURLsWithRole() failed with error -10810

googling shows this problem with a number of other applications distributed by other people that have nothing to do with proclipsing, processing, or java, and the fixes are widely varied and none really seem applicable. based on my googling, however, i thought it might be a permissions-related issue. i tried setting the most lenient permissions possible on the application and all the files within, via:

chmod -R 777 .

listing the files and permissions with ls -l, i can tell this set permissions correctly, but i still get the same LSOpenURLsWithRole() -10810 error. i've tried reinstalling eclipse and proclipsing, as well as wiping my workspace and starting clean, and nothing is working.

also, i have two users both set up to use eclipse; this was not a problem previously, so i don't think it is now, but figured it was worth mentioning.

help?? even if anyone has suggestions for a more unix-savvy forum i'm open to hear them. i really have no idea what the hell is going on and in the meantime i can't export anything to application...big problem for me.

thanks...

serial in 2.0a4

[0 Replies]
- 22-Dec-2011 03:59 PM
- Forum: Core Library Questions
serial is broken in 2.0a4. but! someone figured out a workaround:
http://code.google.com/p/processing/issues/detail?id=944

it ain't pretty but it gets the job done. posting here to save others' hair.

multiply filter for PImage?

[7 Replies]
- 09-Nov-2011 06:30 PM
- Forum: Programming Questions
tint() appears to be additive -- regardless of colorMode(), the parameters to tint() are always added to each pixel.

is there a multiplicative version of tint()? i ask because i'd like to desaturate an image. i can make a copy of the PImage, desaturate it completely with filter(GRAY), and then blend() the two. but it seems like that process could be simpler.

e.g. as3's ColorTransform class has both a multiplier and an 'offset' for each channel; the offsets correspond to the params to tint().

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/geom/ColorTransform.html

but as far as i can tell there's no equivalent in processing for the multipliers.

maybe there's an obvious answer, but i'm not finding it...help?

how to tell if renderer is 3D?

[5 Replies]
- 04-Nov-2011 11:56 PM
- Forum: Library and Tool Development
in my scenegraph library ( http://transmote.com/nest/), i need to be able to tell if the current renderer is 3D or 2D. i had a line:
1. bRendererIs3D = !(p.g instanceof PGraphics2D || p.g instanceof PGraphicsJava2D);
but PGraphics2D no longer exists in 2.0. so, i changed it to:
1. bRendererIs3D = !(p.g instanceof PGraphics || p.g instanceof PGraphicsJava2D);
which works fine...but i'm wondering if there's a smarter, more maintainable way, so i don't have to do this again when renderers are added/removed/renamed, when the using libs that provide other renderers (e.g. GLGraphics, tho yes i know it's integrated into v2.0), etc.

any idears?

fullscreen across multiple monitors

[0 Replies]
- 15-Aug-2011 04:33 PM
- Forum: General Discussion
i know this has been asked before, but i can't find the threads (perhaps they were on the beta forums?).

anyway, casey just shared this with us:

http://wiki.processing.org/w/Fullscreen_on_multiple_monitors

very handy. just wanted to get the word out.

glyph height?

[7 Replies]
- 15-Aug-2011 11:41 AM
- Forum: Core Library Questions
it would be useful to know the height of text drawn with a given font.

font.getGlyph() seems like the route to go for this, using a standard character (e.g. 'A') to get metrics. however, i can't access any of the fields of Glyph, even though Glyph is a public class, and its fields (e.g. height) are public as well.

maybe this is an inner class thing? just wondering why i can't access Glyph's fields.

thanks!

line feed in xml?

[2 Replies]
- 25-Jul-2011 01:36 PM
- Forum: Programming Questions
i'm trying to write a line feed into a String attribute in my xml, parsed on the processing side via XMLElement.getString(). using \n works fine with a String literal, but gets escaped to \\n by the processing.xml lib, which means my parsed xml actually contains a '\n' within (instead of a line feed).

what's the best way to write a line feed into my xml attribute, for processing's consumption? unicode? something else? is there a way to unescape the value returned by XMLElement.getString() (without adding org.apache.commons.lang.StringEscapeUtils, which is massively bloated)?

thanks!

Nest: scenegraph and events for Processing

[19 Replies]
- 08-Jun-2011 11:38 PM
- Forum: Library and Tool Development
I posted previously about a library i wrote that provides a parent-child scenegraph structure and a simple implementation of the DOM event model. i've made updates, and renamed the library, so am re-posting here.

from the library's webpage:

Nest provides a high-level, simple scenegraph for Processing, loosely following the API for the scenegraph and display list implemented by ActionScript 3.

Nest is targeted toward Processing developers familiar with AS3, who wish to organize on-screen objects in a display list hierarchy. As with the AS3 display list, Nest establishes parent-child relationships, applies parent transformations to children, and allows easy manipulation of on-screen objects through member variables such as x, y, rotation, and scale.

Nest also includes an event-based communication system, built on the Observer pattern as implemented by Java's Observer interface. It loosely follows elements of the AS3 / DOM Event Model.
i've tried to be good about documentation and examples. hopefully some find this useful.
enjoy!

-eric

proclipsing and v1.5+

[6 Replies]
- 26-May-2011 04:44 PM
- Forum: Library and Tool Development
just noticed that proclipsing doesn't play nice with processing v1.5+, because of the introduction of modes (with the libraries folder moved into modes/java).

workaround for OSX:

ctrl-click Processing.app > Show Package Contents

copy Contents/Resources/Java/modes/java/libraries folder into Contents/Resources/Java/

proclipsing looks for processing libs in Contents/Resources/Java/libraries, so this helps things out. seems like the IDE still runs fine with this hack.

EDIT:

oh whoops, just update proclipsing. thanks matt!

http://code.google.com/p/proclipsing/issues/detail?id=24#c1

actionscript-style processing scenegraph

[2 Replies]
- 03-May-2011 09:25 PM
- Forum: Library and Tool Development
hey there. i've been working on some more complex processing/java projects at work lately, and found myself missing some of the niceties of AS3, like add/removeChild(), setting .x or .scaleY or .rotationZ, adding event handlers, etc.

so, i started to write a framework to provide some of those things. now, it's all documented and pretty and waiting for you:
http://transmote.com/psg/

please try it out and let me know what you think. i've found it useful in some ways.

i'm hoping to polish up events a bit, encapsulating awt input events (MouseEvent and KeyEvent) so that they can hold information like event phase and currentTarget, and also provide more control over bubbling / event propagation. but figured i'd just get out what i have now and see where that goes.

-eric

increase matrix stack depth?

[2 Replies]
- 17-Apr-2011 11:09 PM
- Forum: Core Library Questions
for some recursive fun, i'd like to nest matrix transformations deeper than the maximum allowed by PApplet. specifically, it looks like PGraphics maxes the stack at 32 transformations deep:
1. ```
static final int MATRIX_STACK_DEPTH = 32;
```
i guess since it's a final, it's not modifiable and that's that. any ideas why there's no API to increase this value?

Activity Trend