We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpPrograms › Multi-Thread or PDF in memory
Page Index Toggle Pages: 1
Multi-Thread or PDF in memory (Read 885 times)
Multi-Thread or PDF in memory
Jul 25th, 2006, 12:00am
 
I've ran into a memory wall concerning the PDF library. Big applet size >= crash out the memory. But I don't want a small PDF because the lines are too thick. My output is so complex it is impossible to edit in Illustrator (CS2 and on a G5!).

The only solution is to run pdf with out producing a graphics window (tried boosting memory - tried more powerful computers).

I'd like to make this into an application though. My first idea was to get pdf to output whilst the applet was small using beginRaw() and a pdf object. I couln't get this to work. It kept defaulting to the PApplet settings - and I couldn't see a way round this in the library code. Maybe I'm wrong.

The multi-thread idea is that I run a size(width, height, PDF, "yadda.pdf") applet for the output. This would be initiated by a primary applet that serves as a console to the PDF generator.

Any suggestions please?
Re: Multi-Thread or PDF in memory
Reply #1 - Jul 25th, 2006, 8:53am
 
The hard way:

Using the SimplePostscript library to Marius Watz, and writing your own appendToFile script (http://www.javacoffeebreak.com/faq/faq0086.html)
then using some Adobe program to convert to PDF.

P.s. Append to file should be an option in all the saveFunctions, shouldn't it?

-seltar
Re: Multi-Thread or PDF in memory
Reply #2 - Jul 26th, 2006, 3:19pm
 
what do you mean by big applet size crashes the memory? if you're using a recent release, you shouldn't even get an applet window with size(x, y, PDF, "blah.pdf").
Re: Multi-Thread or PDF in memory
Reply #3 - Jul 27th, 2006, 1:41am
 
To clarify:

I tried with applet,

crash.

Without,

Joy.

But at a certain size (sans applet) I still manage to crash Processing. No cause for concern - this is some heavy ass pdf work I'm outputting and I'm quite suprised that the pdf library allowed me 10 times more pixel joy for the Bresen-Jam than the Illustrator library.

The question was about creating an application for this sketch. But in all honesty am indeed just running the near equivalent of the following code:
Code:

while(true){
//die computer die!!
}
Re: Multi-Thread or PDF in memory
Reply #4 - Jul 27th, 2006, 9:34pm
 
...which will hork any applet, PDF or not. it's nothing to do with the geometry, you're just starving the machine of all its resources. try to make it run inside the draw() loop or sleep the thread (call delay(5) or something) inside the while().
Re: Multi-Thread or PDF in memory
Reply #5 - Jul 29th, 2006, 6:05pm
 
Sorry, I was using an analogy.

Code and test images here

The applet code is below. Only the bline function is ommitted and all that does is return the amount of pixels not of a color on a line.

Code:

import processing.pdf.*;

boolean operationComplete = false; //Finished drawing?
boolean savedFile = false; //Saved file?
boolean pixel = false; //Draw pixel rectangles?
boolean lines = true; //Draw lines?
boolean quadDraw = false; //Draw only in 4 directions?
PImage scan; //Image to scan
int col; //Current colour
int i = 0; //Iteration
int magnify = 20; //Scaling
int getRow = -1; //Row counter
void setup(){
//Run once then rectify actual scan dimensions
size(212 * magnify, 160 * magnify, PDF, "vector.pdf");
//change to appropriate file
scan = loadImage("logoc.gif");
println("wide:" + scan.width + " high:" + scan.height);
background(255);
rectMode(CENTER);
scan.loadPixels();
noFill();
}

void draw(){
if(!operationComplete){
col = scan.pixels[i];
if(col != #FFFFFF){
if(lines){
for(int j = 0; j < scan.pixels.length; j++){
int xj = j % scan.width;
int yj = j / scan.width;
int xi = i % scan.width;
int yi = i / scan.width;
if(i != j && xj >= xi && !(xj == xi && yj < yi) && !(quadDraw && (xj != xi && yj != yi && (abs(xj - xi) != abs(yj - yi))))){
if(bline(i % scan.width, i / scan.width, j % scan.width, j / scan.width, col, scan) == 0){
stroke(col);
line((i % scan.width)*magnify, (i / scan.width)*magnify, (j % scan.width)*magnify, (j / scan.width)*magnify);
}
else{
stroke(0);
}
}
}
}
if(pixel){
fill(col);
rect((i % scan.width)*magnify, (i / scan.width)*magnify, magnify, magnify);
}
}
if (i == scan.pixels.length - 1){
operationComplete = true;
}
else{
i++;
int yi = i / scan.width;
if(yi > getRow){
getRow = yi;
println("Scanning row:" + getRow + " of " + scan.height);
}
}
if(operationComplete && !savedFile){
exit();
savedFile = true;
println("all done");
}
}
}

It generally breaks with an image larger than depicted in the code. My thought was that this is normal. The only weird thing about it is that the power of the computer is irrelevant, at a certain size it breaks.
Page Index Toggle Pages: 1