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.
IndexProcessing DevelopmentLibraries,  Tool Development › fullscreen-api, future development...
Page Index Toggle Pages: 1
fullscreen-api, future development... (Read 6281 times)
fullscreen-api, future development...
Nov 26th, 2009, 10:37am
 
Hey All!

I'm the developer of the fullscreen API (http://www.superduper.org/processing/fullscreen ).
There are tons of features that _could_ be implemented, however, I want to focus on a small, simple library that handles what most people need.

What would you expect from such a library?
To me it seems the most-demanded feature is dual- (or multi-)screen support, which does work, but imho not in a simple way.

If you could post pseudocode for this or other features I promise I'll carefully consider as much as I can for the next version...

Here are my five cents how I imagine the next version with "nicer" multiscreen support:

Code:

void setup(){
// fullscreen object for main screen + a secondary screen.
fs = new FullScreen( this, "secondary" );

// if you have three screens you can do this:
// fs = new FullScreen( this, "second", "third" );
}

// draw the main sketch
void draw(){
 background( 0 );
 // ...
}


// called by the fullscreen api to initialize the sketch for the
// secondary screen
void setupSecondary( PApplet sketch ){
 sketch.size( 300, 300 );
}

void drawSecondary( PApplet secondary ){
 secondary.background( 255 );
 // ...
}

void mousePressedSecondary( PApplet secondary ){
// ...
}



Another feature I could think of is fullscreen-support for applets, but I'm under the impression that most people hate applets so much, most sketches are exported to apps anyways...

Well, it's christmas is approaching... make your wishes Smiley
Re: fullscreen-api, future development...
Reply #1 - Nov 26th, 2009, 11:20am
 
Thank you very much for this very useful contribution !  Smiley
Re: fullscreen-api, future development...
Reply #2 - Dec 5th, 2009, 7:08am
 
Ok, I'll just add a second proposal, which is semi-implemented already ( the really brave ones with some java experience and an urge to experiment can fetch some development code from github.com/kritzikratzi/fullscreen-p5 )


The idea is _instead_ of creating multiple sketches (like proposed in my first post) to create only one sketch and then to crop rectangles out of the sketch and assign them to screens. like so:  

Code:


void setup(){
 size( 2000, 800 ); // whatever size you want...
 fs = new FullScreen();
 fs.assign(
   0, new Rectangle( 0, 0, 400, 400 ), // map a 400x400 rectangle to screen 0
   1, new Rectangle( 400, 0, 1600, 800 ) // map a translated 1600x800   rectangle to screen 1
}


void draw(){
 // draw background things for both screens
 background( 0 );


 // translate coordinate system to draw on screen 1
 translate( 400, 0 );
}



By default the entire sketch will be mapped to the first screen that is found.
Re: fullscreen-api, future development...
Reply #3 - Jan 2nd, 2010, 12:41pm
 
hansi wrote on Dec 5th, 2009, 7:08am:
The idea is _instead_ of creating multiple sketches (like proposed in my first post) to create only one sketch and then to crop rectangles out of the sketch and assign them to screens.


While that would probably make the API simpler to implement, it would IMHO get more difficult to use and create several issues, e.g.:
  • Need to track the drawing areas in the application (Use case: the screens do not display one big continuous image – as in the Most Pixels Ever lib –, but represent different views like e.g. control interface and output)
  • Forced to use the same rendering method on all screens
  • Wasted memory (and probably degraded performance) when using screens with different resolutions.


Ideally, we would be able to setup the fullscreen mode both either as a big continuum stretching several screens or as several independent screens.

In the second case, the secondary, tertiary, … screens should IMHO be used just like a regular PGraphics object. The API should stay with using _one_ common setup and draw method for all screens, and not use callbacks etc. as proposed in the initial posting. The FullScreen object could simply maintain a list of available screens implementing the PGraphics interface that could be accessed from the application with an accessor method with a signature like e.g. Code:
public PGraphics FullScreen.screen(Enum index) 

or such. Thus the API would IMHO scale better and we stay with one sketch instead of rendering several sketches in parallel.
Re: fullscreen-api, future development...
Reply #4 - Jan 3rd, 2010, 8:03am
 
I'm not sure how it would be best to implement this or if it is possible to overcome this issue with the rectangle suggestion.. but I'll describe the issue that I have with multiple screens.

I make a sketch that has left bound, right bound, top bound, and bottom bound GUI aspects.  A GUI panel is brought up in the center of the screen based on some distance from the top, left, right, bottom.  So what happens when you go to two screens?  The GUI ends up right in the middle, split by the two monitors.  Again, not sure how to fix that.. but that's my main issue.
Re: fullscreen-api, future development...
Reply #5 - Jan 3rd, 2010, 8:21am
 
jeffg wrote on Jan 3rd, 2010, 8:03am:
I'm not sure how it would be best to implement this or if it is possible to overcome this issue with the rectangle suggestion.. but I'll describe the issue that I have with multiple screens.

I make a sketch that has left bound, right bound, top bound, and bottom bound GUI aspects.  A GUI panel is brought up in the center of the screen based on some distance from the top, left, right, bottom.  So what happens when you go to two screens  The GUI ends up right in the middle, split by the two monitors.  Again, not sure how to fix that.. but that's my main issue.


imho the best thing to do in a situation like this is to center the gui panel on the first (or second) screen only, leaving the other screen completely with the visuals.

but there's also cases where you'd want this behaviour (e.g. you have to projectors that create one giant widescreen image)
Re: fullscreen-api, future development...
Reply #6 - Jan 3rd, 2010, 8:42am
 
brsma wrote on Jan 2nd, 2010, 12:41pm:
While that would probably make the API simpler to implement, it would IMHO get more difficult to use and create several issues, e.g.: [...]


Hm... there's some interresting points you make.
Need to think things through.

The only thing I can say for sure is that I don't like the idea of mixing multiple renderers in one sketch. You wouldn't be able to share resources (as PImages) and thus I think it's more confusing than it helps.
Re: fullscreen-api, future development...
Reply #7 - Jan 4th, 2010, 8:08am
 
hansi wrote on Jan 3rd, 2010, 8:42am:
The only thing I can say for sure is that I don't like the idea of mixing multiple renderers in one sketch. You wouldn't be able to share resources (as PImages) and thus I think it's more confusing than it helps.


Agreed, that's reasonable.
Re: fullscreen-api, future development...
Reply #8 - Jan 13th, 2010, 12:11pm
 
Probably a single renderer and multiple frame buffers is more widely used approach.
Re: fullscreen-api, future development...
Reply #9 - Jan 23rd, 2010, 7:29pm
 
I have a wish list:

For VJ purpose, I want two windows launched from one Processing app, the first is the controller, where it displays sliders and and buttons PLUS preview of my final animation, the second window only draws the final animation (without the UI). There is a VJ app called Touch Designer that does this, it previews the final animation in the background of the UI environment, an output object outputs the visuals to the second desktop.

see this screen shot:
http://www.todaycreate.com/wp-content/creations/2009/08/touch_particle_system.jpg

Maybe there is already a way to do this, I found code at a forum post (line below) for drawing two windows but can't figure out how to display same sketches on both windows and do it efficiently.
Re: fullscreen-api, future development...
Reply #10 - Jan 24th, 2010, 8:54am
 
vjfader wrote on Jan 23rd, 2010, 7:29pm:
I have a wish list:

For VJ purpose, I want two windows launched from one Processing app, the first is the controller, where it displays sliders and and buttons PLUS preview of my final animation, the second window only draws the final animation (without the UI). There is a VJ app called Touch Designer that does this, it previews the final animation in the background of the UI environment, an output object outputs the visuals to the second desktop.

see this screen shot:
http://www.todaycreate.com/wp-content/creations/2009/08/touch_particle_system.jpg

Maybe there is already a way to do this, I found code at a forum post (line below) for drawing two windows but can't figure out how to display same sketches on both windows and do it efficiently.



Hey!

This seems to be a very reasonable case to me.
I will definitely make sure situations like this are easy to handle... (and eventually include an example that shows how to do exactly what you asked for)

Thanks for your input!

best, hansi.
p.s. oh... I hope I don't get you all too excited... university is killing me right now and this will have to wait a few more month...

p.p.s. If anyone wants to post their fullscreen dream-scenarios please go ahead. The more input I get the more general I can make it...
Re: fullscreen-api, future development...
Reply #11 - Jan 25th, 2010, 5:14am
 
I second the request for a UI window and a separate fullscreen ("output") window. Perhaps this can already be done using G4P or something... *tinker*

-spxl
Re: fullscreen-api, future development...
Reply #12 - Jan 27th, 2010, 1:01am
 
hansi wrote on Jan 24th, 2010, 8:54am:
p.s. oh... I hope I don't get you all too excited... university is killing me right now and this will have to wait a few more month...


a few more month... will be patiently waiting. In the mean time, I am running two sketches simultaneously with one being Master talking to the Slave via MIDI, a terrible dual screen hack but sort of working.
Page Index Toggle Pages: 1