Bug 282 : blank screen on linux when running programs
Last modified: 2007-10-20 09:46



Assigned To:

Attachment Type Created Size Actions
Small test to reproduce and avoid the bug. application/zip 2007-01-12 10:27 624 bytes

Description:   Opened: 2006-02-04 05:42
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

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.
Additional Comment #1 From fry 2006-02-04 07:49
have you tried it with the included java 1.4?
Additional Comment #2 From makuz 2006-02-04 09:40
yes, i have. i ran the processing batch script that uses jikes.
Additional Comment #3 From fry 2006-02-06 06:56
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.
Additional Comment #4 From makuz 2006-02-19 02:14
were you able to reproduce the problem on your box?
Additional Comment #5 From fry 2006-02-19 09:23
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.
Additional Comment #6 From makuz 2006-02-20 09:47
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.
Additional Comment #7 From fry 2006-02-20 09:49
then in what types of sketches does it occur?
Additional Comment #8 From makuz 2006-02-20 11:35
going through some example sketches again showed that i was wrong. it has
no connection with P3D.

no problem:

color/creating, reading

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?
Additional Comment #9 From akreis@gmx.net 2006-03-22 14:03

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

but i have no problem with this example:

Additional Comment #10 From makuz 2006-03-24 02:21
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.
Additional Comment #11 From fry 2006-03-24 07:15
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.
Additional Comment #12 From makuz 2006-03-24 13:19
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
Additional Comment #13 From fry 2006-03-25 13:28
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.
Additional Comment #14 From makuz 2006-04-03 08:13
commenting out applet.setupFrameResizeListener() in line 307 from
Runner.java solved the problem. can this be an issue of wrong setBounds
Additional Comment #15 From fry 2006-04-17 12:37
hm, that sorta sounds like a thread locking issue, or a video card problem. i'll check into it.
Additional Comment #16 From makuz 2006-04-19 05:46
let me know if i can help.
Additional Comment #17 From fry 2006-05-12 08:54
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:
Additional Comment #18 From fry 2006-08-03 19:55
may be fixed with the threading changes in 0116.
Additional Comment #19 From makuz 2006-08-13 02:33
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.
Additional Comment #20 From fry 2006-08-16 08:20
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.
Additional Comment #21 From makuz 2006-11-10 09:52
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.
Additional Comment #22 From fry 2006-11-12 14:52
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.
Additional Comment #23 From makuz 2006-11-21 11:15
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.
Additional Comment #24 From Sebastien Bailard 2006-11-29 16:47
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

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!


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.
Additional Comment #25 From Sebastien Bailard 2006-11-29 19:55
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);
Additional Comment #26 From fry 2006-11-29 19:59
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.
Additional Comment #27 From Sebastien Bailard 2006-11-29 22:53
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:

import processing.opengl.*;
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.
Additional Comment #28 From Sebastien Bailard 2006-12-13 18:30
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.
Additional Comment #29 From fry 2006-12-15 08:03
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.
Additional Comment #30 From Ricard 2007-01-12 10:27
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.
Additional Comment #31 From fry 2007-01-29 20:11
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.
Additional Comment #32 From fry 2007-06-24 12:19
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.
Additional Comment #33 From Ricard 2007-06-25 10:08
Muy bien!!!
It works for me! I'm on a:
Ubuntu 7.04 Feisty
Linux 2.6.20-16-386

It seems you've nailed down the threading issues.
Congrats and thank you!
Additional Comment #34 From fry 2007-06-28 04:53
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.
Additional Comment #35 From makuz 2007-07-21 01:49
i tried 0125 and the bug seems to be fixed. thank you. great work.
Additional Comment #36 From fry 2007-07-21 04:45
great, thanks for checking.
Additional Comment #37 From stungeye 2007-10-20 08:56
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.
Additional Comment #38 From fry 2007-10-20 09:03
that's a different problem, which should be fixed in 0130, please download
that release.
Additional Comment #39 From stungeye 2007-10-20 09:46
(In reply to comment #38)
> that's a different problem, which should be fixed in 0130, please
> that release.

Yes. All is good now with 0130. Thanks.