rahulpathakgit / codeswarm

Automatically exported from code.google.com/p/codeswarm
GNU General Public License v3.0
0 stars 0 forks source link

Headless mode #37

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
It'd be nice to have a 'headless mode' that will just generate the png's
without any further gui.

Original issue reported on code.google.com by arnout.engelen on 9 Aug 2008 at 12:36

GoogleCodeExporter commented 8 years ago
changed to an enhancement

Original comment by nawglan on 9 Aug 2008 at 1:16

GoogleCodeExporter commented 8 years ago
code_swarm runs great on my own machine, but I've got a lot of visualizations 
I'd
like to make, and I'd like to offload the work onto a more powerful server.

Here's the error that I get when running it on a headless server:

>>    ~/code_swarm $ ant run
>>    Buildfile: build.xml
>>    
>>    init:
>>         [echo] Running INIT
>>    
>>    build:
>>         [echo] Running BUILD
>>    
>>    jar:
>>         [echo] Running JAR
>>    
>>    run:
>>         [echo] Running code_swarm
>>         [java] Exception in thread "main" 
java.lang.ExceptionInInitializerError
>>         [java] Caused by: java.awt.HeadlessException: 
>>         [java] No X11 DISPLAY variable was set, but this program performed an
operation which requires it.
>>         [java]   at
sun.awt.HeadlessToolkit.getMenuShortcutKeyMask(HeadlessToolkit.java:199)
>>         [java]   at processing.core.PApplet.<clinit>(PApplet.java:202)
>>         [java] Java Result: 1

I tried adding -Djava.awt.headless=true to the java invocation in run.sh with 
the
same result.  

Original comment by ric...@gmail.com on 13 Aug 2008 at 1:38

GoogleCodeExporter commented 8 years ago
This is a great feature that will make rendering those large projects less of a
headache. I don't know how coupled we are right now with the display. I'm 
reading
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ right 
now to
see what we can do about it.

Original comment by michael....@gmail.com on 17 Aug 2008 at 1:10

GoogleCodeExporter commented 8 years ago
Yeap I vote for this too.

Original comment by felipe.contreras on 30 Aug 2008 at 11:30

GoogleCodeExporter commented 8 years ago
This feature would interest me as well.

Original comment by dlidstrom on 19 Sep 2008 at 11:07

GoogleCodeExporter commented 8 years ago
Any success or news on that? I'd be definitely leaving these rendering tasks to 
a low
traffic server.

Original comment by asistenc...@gmail.com on 11 Jan 2009 at 2:40

GoogleCodeExporter commented 8 years ago
Just my 2c, hopefully it can make some other person's research shorter than 
mine.

Rather than start monkeying around in the source code (or while I'm getting set 
for
it :P) I've managed to successfully get code_swarm in a headless-alike rendering
task, via Xvfb (a fake X11 for headless boxes):

sudo apt-get install xfvb
#At this stage check that you have xauth, xbase-clients, fixed fonts and such..
#if everytthing's fine running 'Xvfb :0 -screen 0 1024x768x16 &' shouldn't 
throw any 
# error.
# Then you could run code_swarm in ~headless mode with:
xvfb-run -n 0 -a -w 10 ./run.sh data/my_project.config &

Looking at some other Java projects that were originally conceived as applets 
and
were later tried as web services, I had the feeling that making all these
linux/Xwindow-specific details clear here is a good idea. Sorry if it looks 
offtopic
or something.

While my renders ends, I'd get my hands into the Processing thing and see 
what's the
problem with awt.headless.

Best regards.

Original comment by asistenc...@gmail.com on 12 Jan 2009 at 2:45

GoogleCodeExporter commented 8 years ago
I vote for it too.
(sorry, long time not speaking here)

Original comment by jp.caru...@gmail.com on 4 Mar 2009 at 4:47

GoogleCodeExporter commented 8 years ago
I have also been reading up on this. The latest topic about "headless" mode and 
the 
Processing libraries is not promising (Reply #8 - Nov 10th, 2007 
http://processing.org/discourse/yabb2/YaBB.pl?num=1193317878). They are 
suggesting 
to incorporate PJA with Processing but it looks as though there has been no 
activity 
on this topic in a long time. Maybe there is another Java solution for writing 
graphics and we can phase out the Processing library alltogether? Perhaps PJA 
http://www.eteks.com/pja/en/ could replace it. I do not have a great knowledge 
of 
Processing so I can not comment any further.

Original comment by tj.pi...@gmail.com on 19 Apr 2009 at 3:18

GoogleCodeExporter commented 8 years ago
A headless version would be helpful for me too.

I got the command

xvfb-run -n 0 -a -w 10 ./run.sh data/my_project.config

to work for me but just thinking of all those wasted cycles rendering to a 
buffer
that is ignored. A proper headless version would be greatly appreciated.

Original comment by Slick...@gmail.com on 4 Jun 2010 at 12:06

GoogleCodeExporter commented 8 years ago
Adding to my earlier comment using xvfb causes the program to run really REALLY 
slow.
It's also only using one of the four cores that my processor has it's been 
running
for 70 hours and only produced 3890 frames (640x480). this should really be 
fixed in
the application itself. 

Original comment by Slick...@gmail.com on 7 Jun 2010 at 11:47