i'm getting a blank screen when running sketches from the processing gui on
linux. sometimes the real content is shown (maybe once out of 20 tries),
but usually it is just blank. when i export the applets they work fine. it
tried several programs from the sketchbook and the results were always the
same.

i tried version 103 and 99, they had the same problem, although version 98
worked fine.

my system is fedora core 4, kernel 2.6.15, jre 1.5.0_06.

have you tried it with the included java 1.4?

yes, i have. i ran the processing batch script that uses jikes.

bummer, i'll check on my fedora box here and see if i can get it to break.
i believe some threading stuff changed between 98 and 99 so that always
causes cross-platform headaches.

were you able to reproduce the problem on your box?

it's working fine on my box here (fedora core 4, the latest download, and the included versions
of java and jikes). problem could be the graphics card or a strange threading issue (are you on
a dual processor machine?) but i'm not seeing anything as yet.

it's a thinkpad t40 laptop. the graphics card is a radeon 7500, the cpu is
intel pentium 1500mhz. it's not a dual processor machine.
i also realized that the problem does not occur in P3D sketches.

then in what types of sketches does it occur?

going through some example sketches again showed that i was wrong. it has
no connection with P3D.

no problem:
3d-camera/all
3d-form/rgbcube
3d-lights/all
3d-transforms/all
color/relativity

problem:
color/creating, reading
control/all
3d-form/primitives3d,vertices3d
form/all

there was an interesting effect with form/simplecurves. the curves are
always drawn, but the black background is missing sometimes, it defaults to
grey instead. can this problem be an issue of the color functions?

hi..

i have the same problem on my ubuntu/linux.

ubuntu version breezy
java version 1.5.0_06

if i try to running the following example, i get a blank screen
http://processing.org/learning/examples/widthheight.html

but i have no problem with this example:
http://processing.org/learning/examples/letterk.html

thanks. i started to think that the problem is in my system.

is it possible to get the source code of processing 98 and 99 and compare
them? i'm willing to help compare and test. i really wouldn't lilke to miss
out the improvements of the newer revisions and stick to revision 98,
because that's the last which is working on linux.

yep, just go to http://dev.processing.org/source/index.cgi/ and then "tags", where you'll see a
tag for both 98 and 99. then you can browse the code for each, or from the 99 tag, select both
the 98 and 99 versions of a file for a diff.

i copied app/Runner.java and core/PApplet.java from revision 98 to 99,
compiled the code and everything seems to work. it is probably a threading
issue.

i'd suspect Runner, but let me know if anything pops out in the diffs
between the two. or i'll get to it when i get a chance.

commenting out applet.setupFrameResizeListener() in line 307 from
Runner.java solved the problem. can this be an issue of wrong setBounds
parameters?

hm, that sorta sounds like a thread locking issue, or a video card problem. i'll check into it.

let me know if i can help.

this also seems to be related, two more examples showing screens that
either won't show up, or don't properly render the first frame (only
subsequent frames) on linux:
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=SoftwareBugs;action=display;num=1145632475

may be fixed with the threading changes in 0116.

i tried 0116 beta from subversion and i'm afraid the problem still
persists. the applet.setupFrameResizeListener(); hack mentioned above fixes
it, but i can't see why.

k, it's just a quirk then, and i have some ideas about how to fix it.
thanks for looking into it for me, that's a huge help.

the problem still persist in processing 121, although i found a workaround.
i updated to fedora core 6 which has compiz (opengl-accelerated compositing
window manager for the x window system) built in. if i switch compiz on
(system->preferences->desktop effects) , the processing sketches run fine
from the gui.

if you are having similar problems it would be worth trying this out. maybe
beryl (a fork of compiz) on ubuntu also works.

hm, interesting.. i'm still stuck on this one because i can't replicate it,
unfortunately, on either an ubuntu box running on amd64 (tho i guess we're
using 32bit java there) or another running fc4. i assume it's part of a
broader set of threading issues that have to be dealt with, which will just
require me to have a chance to sit down and crank through them all.

i can reproduce the problem on both of the machines i have access to.
formerly they were running fc4, then fc5, now fc6. all of these setups had
the problem.
i looked at the code of processing, but i\'m not that familiar with java
unfortunately. if you have some idea how i can help you with this, running
some test code or whatever, just let me know.

I'm also having this problem with all three of my debian systems. In
0012, Ortho behaves correctly,. RGB cube gives a dark grey square, and
array2d gives a black square. Letter K does work, but the three segments
of the letter have black thin outlines, unlike in
http://processing.org/learning/examples/letterk.html

0068 does work on my system, until I tried it I was under the impression
processing was just broken for linux.

I could not get compiz to work on my system. I have not tried tinkering
with Runner.java yet (wherever it is).

Also, middle-clicking does not paste the content from the xwindow
clipboard, unlike all my other applications. I will look into using emacs
as my editor.

Still, thanks for writing the program!


Stats:

Linux version 2.6.17 (root@Knoppix) (gcc version 4.0.4 20060507
(prerelease) (Debian 4.0.3-3)) #4 SMP PREEMPT Wed May 10 13:53:45 CEST 2006

X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN
Current Operating System: Linux kappa 2.6.17 #4 SMP PREEMPT Wed May 10
13:53:45 CEST 2006 i686
Build Date: 07 July 2006

java version "1.4.2_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_11-b06)
Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode)

Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary)

Frustration index: high , but I'm happy 0068 works.

This is odd. I'm mucking about with basic primitives in 0122 under linux.

The following code draws a triangle but not the f our points, when I run
it in opengl.
When I run it in P3D, I see the points and the triangle.

Code follows:

import processing.opengl.*;

void setup()
{
//size(500, 500, OPENGL);
size(500,500, P3D);

}

void draw()
{
stroke(204, 102, 0);
point(30, 20);
point(85, 20);
point(85, 75);
point(30, 75);
fill(204, 102, 0);
triangle(30, 75, 58, 20, 86, 75);
}

please don't fill this bug report with miscellaneous linux issues. this bug
report is for one specific problem--that the window stays blank some
percentage of the time when running under linux. other bugs or issues found
should be filed as separate items.

My apologies, I shall file individual bugs as appropriate in the future.

I noticed that the Array example doesn't work on my machine, but I can make
it work partially by making the window an opengl window:

Adding:
import processing.opengl.*;
Modifying.
size(200, 200,OPENGL);

In this case, rather than getting a blank screen as output, I get the
normal Array output, except for a glitch in the form of an extra vertical
grey line in the middle of the screen.

This trick does not exactly work with Array2D. WIthout adding opengl, the
screen is a black square. With the adding of opengl, I get 10 whitedots on
the screen.

I am not sure if this is helpful.

I tried running 123 (on linux) , but now it gives me a blank screen when I
run my code ( Comment #25). I'll stick with 122, where that code works.)

I've got an ubuntu live cd laying about, I'll see if that fixes things for
me by using different video drivers or a different opengl version.

please let me know what you find. i'm on my third linux box, which still
won't reproduce the problem. it's an amd64 running ubuntu 6 from a livecd
install, and both with and without the radeon drivers it had no problems.

edit]
Small test to reproduce and avoid the bug.

I made a small test for this bug.

The problem must be related to the fact that the setup() doesn't have time to
draw the first frame.

ugh, yeah, so it's related to other threading problems that are in there.
it's one of the "big" things i need to deal with before 1.0. lots of
nastiness and a huge pain to get working properly across all the platforms
once i've made changes. weee!

buuuut.. understand that it's a high priority, i just need to get a good
block of time to work on it.

i think this may be fixed for 0125 along with bug #341. if you get a
chance, please try the latest version from svn to verify.

Muy bien!!!
It works for me! I'm on a:
Ubuntu 7.04 Feisty
Linux 2.6.20-16-386
java.runtime.version=1.4.2_12-b03

It seems you've nailed down the threading issues.
Congrats and thank you!

excellent, thanks for checking into it.

i think what was happening was that a resize event was being fired by the
frame before the PApplet could set itself up properly. since the frame is
usually not resizable, i have it simply ignore those events unless the
frame has been explicitly set to resizable. that way it only picks up user
interaction when necessary.

i tried 0125 and the bug seems to be fixed. thank you. great work.

great, thanks for checking.

I'm still experiencing this bug with 0129 Beta w/ Ubuntu 7.04 AMD64.

My sketch issues "point" methods in the setup and these are not being
rendered. I've also tried writing to the pixel array (using loadPixels and
updatePixels) within the setup.

I've tried "wait"ing before and after the points are issued with no effect.
My guess is that the first frame (the one initialized in the setup method)
is not ready once draw() is called.

I'm launching Processing from the included script.

that's a different problem, which should be fixed in 0130, please download
that release.

(In reply to comment #38)
> that's a different problem, which should be fixed in 0130, please
download
> that release.

Yes. All is good now with 0130. Thanks.