Why are my p5 graphics dimensions scaled up?

Kaylors

  image(graphics, 0, 0);

  graphics.stroke(255);
  graphics.point(
    _.random(0, windowWidth),
    _.random(0, windowHeight)
  );

  graphics.noFill();
  graphics.ellipse(0, 0, 20, 20);

  ellipse(0, 0, 20, 20);

The ellipse drawn on the p5 graphics buffer looks much larger than the one drawn on the main canvas. Any ideas?

Here's a complete sketch demonstrating the problem: http://codepen.io/kaylors/pen/GpXPmq?editors=001

blindfish

You haven't given us any context here: it's like giving us a sentence from a book and asking us what it's about :/

How did you instantiate your graphics buffer? Best to post a complete sketch that demonstrates the problem...

Kaylors

Sorry about that. Here's a complete sketch: http://codepen.io/kaylors/pen/GpXPmq?editors=001

As you can see, the ellipse drawn directly on the canvas is much smaller than the one on the graphics buffer. Am I doing it wrong? Is it a bug? I'm on a Mac using Chrome.

GoToLoop

Dunno whether b/c I don't have any fancy "retina" resolutions, I've just seen 1/4th of 1 white circle from your CodePen.io link. @-)

Just to make sure it wasn't any problem related from those Babel, JQuery & Lodash boilerplates, I've rewritten your problematic example using p5.js only. :ar!

This time I've seen 2 circles of the same size.
Dunno whether it's gonna render likewise for you too though: ^#(^

index.html:

<meta charset=utf8>
<meta name=viewport content=width=device-width,user-scalable=no,initial-scale=1>

<script src=sketch.js></script>
<script src=http://p5js.org/js/p5.min.js></script>

sketch.js:

// forum.Processing.org/two/discussion/13368/
// why-are-my-p5-graphics-dimensions-scaled-up

// 2015-Nov-06

const DIAM = 200, RAD = DIAM>>1;
var pg;

function setup() {
  createCanvas(windowWidth, windowHeight);
  noLoop();

  reconfigureCanvas();
  reconfigureGraphics(pg = createGraphics(width>>1, height));
}

function draw() {
  background(0350);
  ellipse(width>>2, height>>1, DIAM, DIAM);
  image(pg, width>>1, 0);
}

function reconfigureCanvas() {
  ellipseMode(CENTER).imageMode(CORNER);
  smooth().fill('blue').strokeWeight(3).stroke(0);
}

function reconfigureGraphics(pg) {
  pg.ellipseMode(CENTER).smooth().fill('red').strokeWeight(3).stroke(0);
  pg.ellipse(pg.width>>1, pg.height>>1, DIAM, DIAM);
}

function windowResized() {
  resizeCanvas(windowWidth, windowHeight);
  pg._renderer.resize(width>>1, height);

  reconfigureCanvas();
  reconfigureGraphics(pg);

  redraw();
}

blindfish

I'd hazard a guess that your globally declared windowWidth and windowHeight variables are conflicting somehow with the p5js globals windowWidth and windowHeight. Try changing the name of your variables...

var body,
    myWindowWidth,
    myWindowHeight,
    graphics;

function setup() {
  init();
}

function draw() {
  background(0);
  render();
  run();
}

function init() {
  createCanvas(myWindowWidth, myWindowHeight);
  graphics = createGraphics(myWindowWidth, myWindowHeight);
}

function render() {
  image(graphics, 0, 0);


  graphics.fill(255,0,0);
  graphics.ellipse(300, 300, 200, 200);

  ellipse(600, 300, 200, 200);
}

function run() {

}

// self-invoking function:
(function houseKeeping() {
  body = $('body');

  body.resize(init);

  myWindowHeight = body.height();
  myWindowWidth = body.width();
})();

It's possible that the transpiler is making changes that explicitly set scope on function calls - e.g. it may use call() - which might explain why @GoToLoop's version works without them.

[Edit: I hadn't looked at GoToLoop's code thoroughly: note that he doesn't override the p5js variables]

This sort of issue is exactly why I choose to use instance mode in my projects: there's then no doubt when you're referencing a p5js property/method...

GoToLoop

This sort of issue is exactly why I choose to use instance mode in my projects:

If we re-assign p5.js' "system" variables, whether we're in "global" or "instance" modes is completely moot/pointless. >:)

But my guess is that both windowWidth & windowHeight are simply informative variables and thus no internal implementation depends on them! :-\"

P.S.: My refactored example doesn't use any transpilers nor any other libraries but p5.js. :-h
It's just JavaScript compatible w/ all modern browsers. :P

blindfish

If we re-assign p5.js' "system" variables, whether we're in "global" or "instance" modes is completely moot/pointless.

@GoToLoop: I didn't get the impression you had spotted the naming conflict :P

Anyway, my point was that by using instance mode you don't have to worry about re-assigning 'system' variables. Consider the following two sketches:

standard mode

var windowWidth = 100;

function setup() {
    createCanvas(600, 400); 
    console.info(windowWidth);
}

instance mode

var p5 = new p5(function (p) {

    var windowWidth = 100;

    p.setup = function () {
        p.createCanvas(600, 400);
        console.info(windowWidth);
        console.info(p.windowWidth);
    };

}, "sketch01");

Standard mode makes it far too easy for someone unfamiliar with the library to choose a conflicting variable name and get an unexpected result back. I suppose the same is true for Processing. But most beginners will edit Processing in the dedicated IDE which colour-codes known properties/methods; meaning it's more obvious when you've made a conflicting choice. More experienced JS developers will be surprised (maybe even shocked) to find a JS library polluting the global scope in the way p5js does and so may also fall foul of this issue...

P.S.: My refactored example doesn't use any transpilers nor any other libraries but p5.js

Yes I saw the following and hence surmised the transpiler might be the issue:

Just to make sure it wasn't any problem related from those Babel, JQuery & Lodash boilerplates, I've rewritten your problematic example using p5.js only

GoToLoop

... for someone unfamiliar with the library to choose a conflicting variable name...

For any library there's no way around than becoming familiar w/ its basic API gradually.
And indeed w/ "global" mode we can end up overriding anything inadvertently.

I didn't get the impression you had spotted the naming conflict.

Perhaps not at 1st sight. But I became very aware once I've started rewritting my own pure p5.js version.
Although as I've already mentioned, I believe his bug might be related to "retina" display.
And nothing to do w/ reassigning those 2 newly "system" properties which apparently aren't used anywhere internally.

But most beginners will edit Processing in the dedicated IDE which colour-codes...

And btW, for such simple small sketches, I use PDE's "Java Mode" to write p5.js code! 8-}
Since I get color highlights for when their APIs match. *-:)

More experienced JS developers will be surprised (maybe even shocked) to find a JS library polluting the global scope...

All Processing flavors, except OpenFrameworks which is in C++, target beginner & artistic programmers. So it's somewhat irrelevant and we can go on being heretics w/ no remorse. [-O<

Jokes apart, rather than scaring away folks about some doom to befall upon them lest they repent of their wicked ways, we should also try to explain why global scope pollution is frowned upon and normally should be avoided. >:)

Indeed if every library decides to dump their whole API into the window, chaos & war will ensue for sure.
Luck for p5.js, since every other JS library encapsulates theirs, it can freely ill-behave, taint and take all global scope for itself! :-h

As long as only 1 library does that, there's no danger of conflicting APIs.
Therefore for casual sketches, we should just enjoy a verbose-free programming style w/ p5.js! \m/

GoToLoop

But most beginners will edit Processing in the dedicated IDE which colour-codes...

Just remembered that there's a dedicated online p5.js IDE w/ full color highlight support:
http://p5ide.HerokuApp.com/editor

And for easy hosting, there's also p5js.SketchPad.cc w/ "vintage" Processing 1 style coloring: :P
http://p5js.SketchPad.cc/

blindfish

Although as I've already mentioned, I believe his bug might be related to "retina" display. And nothing to do w/ reassigning those 2 newly "system" properties which apparently aren't used anywhere internally.

Yes - I also began to doubt the variable conflict issue being the sole cause when I realised the codepen link worked fine for me with only minor adjustments to the ellipse position, fill etc.

@Kaylors: can you confirm if you still have the issue with my revised code? If so I think GoToLoop might be right...

Kaylors

Seems like it's a retina issue @blindfish @GoToLoop. I ran @blindfish 's code without Babel and lodash though I kept jQuery, and this is what I got.

Any ideas on how to get around it? Something that would work for non-retina as well.

GoToLoop

Dunno whether there's any. :| p5.js claims it supports diff. pixel density values aFaIK.

You can also try out your luck w/ devicePixelScaling():
http://p5js.org/reference/#/p5/devicePixelScaling

Have you also checked my version? Since it relies on p5.js only it should have a better chance to work.

If none of them amends your bug, you should report it below mentioning this forum thread:
https://GitHub.com/processing/p5.js/issues

Kaylors

Yup. Adding a devicePixelScaling(false); to setup() solved the issue.

GoToLoop

Oh. Nice that blind shoot turned out good! <:-P
Anyways, here's my own CodePen.io: http://CodePen.io/anon/pen/PPyKMj?editors=101