Canvas is 1/2 size
shiffman opened this issue · comments
Chrome Version 36.0.1985.125 Mac OS X
Did you resize your browser?
Currently there's no logic to resize the canvas when the window resizes. Is this something that could work with size() in a sketch?
it could be related to the hdpi support scaling. @scottgarner are you manually setting the width/height of the canvas div anywhere? this should be set by p5. I'll take a look at this.
relevant scaling stuff here:
https://github.com/lmccart/p5.js/blob/master/lib/p5.js#L3163
Ah, I am noticing this problem on a retina. (I have not resized the browser.) Can't check now on a non-retina but wouldn't be surprised if this is the issue.
I'm guessing it is as I'm on non-retina and it sounds like @scottgarner also has an older machine. I'll review this and make sure it's all working correctly on the library end. I'm not sure I've tested it with instance mode.
I create the initial canvas in that sketch like this:
sketch.createCanvas(window.innerWidth,window.innerHeight);
Should it be AUTO? It already lives in a div that fills the screen.
On Tue, Jul 29, 2014 at 9:46 AM, Lauren McCarthy notifications@github.com
wrote:
I'm guessing it is as I'm on non-retina and it sounds like @scottgarner
https://github.com/scottgarner also has an older machine. I'll review
this and make sure it's all working correctly on the library end. I'm not
sure I've tested it with instance mode.—
Reply to this email directly or view it on GitHub
#18 (comment)
.
This is working fine on my macbook air. However, I am seeing this from time to time (top of scene cut-off). It might be something I'm doing, trying to reproduce more consistently.
Some of the sketches, like the labels and circle, are positioned dynamically relative to the video. In this case, it looks like your window is just a little too short. I've thought about experimenting with scaling the video within the browser, but that will make the relative positioning a little crazy.
Maybe we don't scale the video, but just push the labels a bit down if we detect a sketch height below a certain threshold? All in all, this isn't a high priority as everything else appears fine.
I guess the other benefit to scaling is for people with huge displays. I'll
experiment a bit.
I may end up restyling these labels completely when I do the intro so that
positioning won't be an issue.
On Tue, Jul 29, 2014 at 9:11 PM, Daniel Shiffman notifications@github.com
wrote:
Maybe we don't scale the video, but just push the labels a bit down if we
detect a sketch height below a certain threshold? All in all, this isn't a
high priority as everything else appears fine.—
Reply to this email directly or view it on GitHub
#18 (comment)
.
Something just occurred to me. @shiffman, is the canvas really half size or is it something in the borders() function? I can't quite tell from your screenshot.
If this helps, when I pause the video and take over main.sketch and set the background to grey I see:
log of my console:
main.sketch.width;
1128
main.sketch.height
779
143.708132 main.js:15
{left:533, top:29} main.js:18
main.sketch.noLoop();
undefined
main.sketch.background(100);
undefined
My screen is 1440x900 so this seems like the right resolution just appearing smaller.
@lmccart, I've been doing some testing on a retina iPad mini. I haven't figured out the flocking example, but the painting example seems to fail like this:
- I create a canvas at 1280x800 and p5 doubles this per the pixel ratio and displays it at half the size.
- I create offscreen buffers at 1280x800 with createGraphics. p5 doesn't double these.
- I draw the buffer canvases to the main canvas and they only fill part of the screen because the ratio isn't accounted for, even though from a user perspective they were set to the same size.
You can see this behavior on non-retina displays by manually setting this._pixelDensity to 2.
I think it would be nice to offer a means to disable the pixel adjustment, too. The iPad mini works fine with the ratio set to 1, but setting it to 2 means four times the pixels and it really bogs down.
ohh wow good find, thank you! I will fix this this afternoon. and an option to turn off pixelDensity scaling.
for now, if you want to disable scaling you can add
sketch._pixelDensity = 1;
before the createCanvas call.
Great, thanks Lauren.
On Fri, Aug 1, 2014 at 3:27 PM, Lauren McCarthy notifications@github.com
wrote:
for now, if you want to disable scaling you can add
sketch._pixelDensity = 1;
before the createCanvas call.
—
Reply to this email directly or view it on GitHub
#18 (comment)
.
@shiffman, I've disabled the pixel density compensation for now. Can you confirm that it works on your retina display?
yup, works great, thanks!
@scottgarner the graphics buffer should be scaling the same as the canvas now if you do want to use the pixel density compensation. but maybe better to leave it off for performance?
Great, it looks like the buffers are created at the proper size, though now
they're double size when shown in the dom. It looks like you'll need the
same css trick for width and height to cut them in half.
Theres also a problem with mouseX and mouseY not corresponding to the right
place on a pixel-doubled canvas. I think there may be a problem with width
as well?
I'll try to make a little sketch that demos the problems later this morning.
On Sat, Aug 2, 2014 at 7:27 AM, Lauren McCarthy notifications@github.com
wrote:
@scottgarner https://github.com/scottgarner the graphics buffer should
be scaling the same as the canvas now if you do want to use the pixel
density compensation. but maybe better to leave it off for performance?—
Reply to this email directly or view it on GitHub
#18 (comment)
.
Okay, I think I found the cause of the problem, but I didn't dig into a solution.
clear() seems to be throwing off the pixel adjustment so that sketch dimensions and mouse positions don't add up. It also throws away stroke and fill settings specified in setup().
And as mentioned above, createGraphics elements need css sizing to show them half size.
Here's a test page:
for the graphics element, isn't the idea here that it's not shown in the dom, it's an offscreen rendering buffer? or are you just using it as a second canvas? either way, I added the css scaling just now, thanks for the test page, I'll look into the problem with clear. I was trying a trick that is supposed to be performance optimized for clearing the canvas but looks like it sort of nukes everything.
ok test page looks good with this commit lmccart/p5.js@1e5e0e3
For the painting sketch, I was using it for offscreen buffers and that's definitely the normal usage in Processing. For other demos, I was using it to create graphical elements that were incorporated in other html. The wind gauge graphic, for example, and the label arrow.
Maybe that shouldn't be supported behavior? Intuitively, it seems like you should be able to create multiple graphical elements and mix them up with other dom elements, but I could see making a case either way.
Ah, right. I've used that width trick before, but I don't think it's the fastest way anymore, even aside from all of the resets. This thread has a lot of discussion on the topic, but I haven't done any speed testing myself.
Great, looks like the clear() fix took care of all of the problems with the painting and flocking sketches.
I'm going to leave pixel density set to 1 for performance until I can do some testing on retina machines, but it's good to know that everything will work.
yeah makes sense about the buffers. I think it's simple enough to support p5.graphics as onscreen elements, too, though it'll be hidden by default. I think I need to do a little more testing of clear to see what happens when there are transforms applied, but I think as long as you call it at the beginning of draw it should be ok.