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.
Index › Programming Questions & Help › Programs › Accessing main graphics instance like PGraphics
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: 1
Accessing main graphics instance like PGraphics? (Read 550 times)
r3ptile
Accessing main graphics instance like PGraphics?
Sep 7th, 2007, 2:22pm  
Hi all, I'm trying to write methods that can render stuff both directly on-screen or to an off-screen-buffer, rather than having separate methods that only draw on-screen or in a buffer.

void renderStuffTo(PGraphics buf)
{
   buf.drawSomeStuff...
}

PGraphics someBuffer = createGraphics(...);
renderTo(someBuffer);
renderTo(<screen?>);

Now what would be the correct way to access the screen like this? I assume that the screen, too, is just a PGraphics object, but how do I address it?
Back to top
 
 
r3ptile
Re: Accessing main graphics instance like PGraphic
Reply #1 - Sep 7th, 2007, 2:36pm  
Oh, don't bother, it seems the correct answer is main.g!

Now I'm wondering if the following method calls would have an  identical outcome in terms of speed etc?

main.g.img(...)
img(...)
Back to top
 
 
fry
Re: Accessing main graphics instance like PGraphic
Reply #2 - Sep 7th, 2007, 3:32pm  
g.image() and image() will be (all but) equivalent in speed. you'll lose begin/endRecord and begin/endRaw however.
Back to top
 
WWW  
r3ptile
Re: Accessing main graphics instance like PGraphic
Reply #3 - Sep 7th, 2007, 4:48pm  
Sorry I might be lost in translation...

So you're saying they _are_ in fact equal in speed, however what did you mean by "(all but) equivalent"?

I can do without beginRecord etc since I am in fact asking the question above in order to render "print resolution" versions of what's on screen (mostly scaled bitmaps) to files. Is there a smart way I'm overlooking? When exporting PDF, will bitmaps I output on-screen using scale(< 1) and then image(some_png_data) have the screen resolution or will Processing take advantage of the fact that the original file had a higher resolution?
Back to top
 
 
JohnG
Re: Accessing main graphics instance like PGraphic
Reply #4 - Sep 7th, 2007, 4:53pm  
I'm fairly sure there's a coupld of chunks of code on the forum, or processing related sites that will give you a "render really big images as lots of smaller files" function.
Back to top
 
 
r3ptile
Re: Accessing main graphics instance like PGraphic
Reply #5 - Sep 7th, 2007, 4:58pm  
That's not what I'm looking for. I want to render one file with the same ratio that the screen has, but with a higher resolution. Since I'm scaling my bitmaps down for on-screen use, this is possible. I'm just wondering about the internals of PDF export, i.e. if used with beginRecord() etc, will bitmaps have the same resolution they have on screen or is it possible to render them in a higher resolution when there's more image pixel data?
Back to top
 
 
JohnG
Re: Accessing main graphics instance like PGraphic
Reply #6 - Sep 7th, 2007, 5:07pm  
Ah okay, the PDF recorder will use the full image data, just shrunk down, rather than resample the image as happens on screen.
Back to top
 
 
jeremymende
Re: Accessing main graphics instance like PGraphic
Reply #7 - Feb 19th, 2008, 10:01pm  
Curious if you received any feedback on your question. We are trying to produce high-res files for offset-litho printing and can't find a way to export files.

Do you know anything about this?

Thanks

-Jeremy
Back to top
 
 
r3ptile
Re: Accessing main graphics instance like PGraphic
Reply #8 - Feb 20th, 2008, 4:35pm  
Since I was exporting bitmap data, I ended up not using the PDF export at all and building a slow, home-cooked export routine.
Back to top
 
 
Page Index Toggle Pages: 1
‹ Previous Topic | Next Topic ›