_2X last call #3361

Closed
benfry opened this Issue Jun 8, 2015 · 19 comments

Comments

Projects
None yet
5 participants
@benfry
Member

benfry commented Jun 8, 2015

One more for @REAS @shiffman and @codeanticode:

So… With all these changes happening with smoothing and whatnot, do we need to revisit the _2X decision?

Basically, we’d have a method that sets retina/2x/hidpi mode (whatever we want to call it), and it’d work just like size(), fullScreen(), smooth(), and noSmooth() (It’d be moved to settings() and in Eclipse, you’d manually put it into settings())

The reasons for using the _2X extension were twofold:

  1. That the decision on 2x has to be made at the time that size() is called and the renderer is set up.
  2. That the code between the retina and non-retina versions of the retina are fairly different, so a second class is better.

But since we made the decision, things have changed:

  • The first item is no different than noSmooth() and smooth(N), so we could add a method for it.
  • The second item isn't the case to the extent we initially thought it was. The Java2D renderer was more different, but OpenGL and JavaFX have almost no changes between retina and non-retina.
@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Jun 8, 2015

Member

I would go for a separate method to enable/disable 2x mode. I find the 2X extension not very satisfactory because it conveys the idea of different renderers for retina and non-retina situations.

Member

codeanticode commented Jun 8, 2015

I would go for a separate method to enable/disable 2x mode. I find the 2X extension not very satisfactory because it conveys the idea of different renderers for retina and non-retina situations.

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Jun 8, 2015

Member

Check out this snippet for the current reference for size:

P2D (Processing 2D): 2D graphics renderer that makes use of OpenGL-compatible graphics hardware.

P3D (Processing 3D): 3D graphics renderer that makes use of OpenGL-compatible graphics hardware.

JAVA2D_2X (Default 2D x 2): A renderer that supports two-dimensional drawing at full resolution on High-DPI and Retina displays.

P2D_2X (Processing 2D x 2): 2D graphics renderer that makes use of OpenGL-compatible graphics hardware at full resolution on High-DPI and Retina displays.

P3D_2X (Processing 3D x 2): 3D graphics renderer that makes use of OpenGL-compatible graphics hardware at full resolution on High-DPI and Retina displays.

It would be nice to just say we have the "default", P2D, and P3D has we have. So as far as I understand the discussion, I prefer having a new function to "enable high resolution." I don't have a good idea for its name yet.

Member

REAS commented Jun 8, 2015

Check out this snippet for the current reference for size:

P2D (Processing 2D): 2D graphics renderer that makes use of OpenGL-compatible graphics hardware.

P3D (Processing 3D): 3D graphics renderer that makes use of OpenGL-compatible graphics hardware.

JAVA2D_2X (Default 2D x 2): A renderer that supports two-dimensional drawing at full resolution on High-DPI and Retina displays.

P2D_2X (Processing 2D x 2): 2D graphics renderer that makes use of OpenGL-compatible graphics hardware at full resolution on High-DPI and Retina displays.

P3D_2X (Processing 3D x 2): 3D graphics renderer that makes use of OpenGL-compatible graphics hardware at full resolution on High-DPI and Retina displays.

It would be nice to just say we have the "default", P2D, and P3D has we have. So as far as I understand the discussion, I prefer having a new function to "enable high resolution." I don't have a good idea for its name yet.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

And the piece I left out... ideas for what to call such a method?

  • pixelFactor(N) to go with what we're using internally at the moment (along with pixelWidth and pixelHeight, the 1x or 2x version of width and height)
  • pixelDensity(2) perhaps a better name? (we'd fix the internals as well)
  • set2x() (we don't use set anywhere)
  • makeLookBetter()
  • iveGotAnExpensiveComputer()
  • highRes()

Other references:

Member

benfry commented Jun 8, 2015

And the piece I left out... ideas for what to call such a method?

  • pixelFactor(N) to go with what we're using internally at the moment (along with pixelWidth and pixelHeight, the 1x or 2x version of width and height)
  • pixelDensity(2) perhaps a better name? (we'd fix the internals as well)
  • set2x() (we don't use set anywhere)
  • makeLookBetter()
  • iveGotAnExpensiveComputer()
  • highRes()

Other references:

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Jun 8, 2015

Member

don't forget highRez()

Member

REAS commented Jun 8, 2015

don't forget highRez()

@benfry

This comment has been minimized.

Show comment
Hide comment
Member

benfry commented Jun 8, 2015

Mmm.. deRezzed()

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Jun 8, 2015

Member

I don't think pixelFactor(N) is intuitive and as you mention, we don't use set for features like this. The pixelDensity(2) option is clear. I'm thinking about how it's called High-DPI on Windows. How does the idea of a pixel transfer into the language around Retina displays, are they called points?

Member

REAS commented Jun 8, 2015

I don't think pixelFactor(N) is intuitive and as you mention, we don't use set for features like this. The pixelDensity(2) option is clear. I'm thinking about how it's called High-DPI on Windows. How does the idea of a pixel transfer into the language around Retina displays, are they called points?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

Yeah, I think it's all over the place. I haven't been able to find consistent references, thus the list. The "retina" name is just marketing, and a highDPI() method seems really awkward.

I'm also warming to pixelDensity()... Though I'm not sure if we'll ever see other pixel densities than 2 (at least in the lifetime of this API).

Member

benfry commented Jun 8, 2015

Yeah, I think it's all over the place. I haven't been able to find consistent references, thus the list. The "retina" name is just marketing, and a highDPI() method seems really awkward.

I'm also warming to pixelDensity()... Though I'm not sure if we'll ever see other pixel densities than 2 (at least in the lifetime of this API).

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Jun 8, 2015

Member

*screenDensity(2)
*pixDensity(2)
*pixelDensity(2)
*pixRes(2)
*pixelResolution(2)

At the moment, I'm in favor of pixelDensity(2)

Member

REAS commented Jun 8, 2015

*screenDensity(2)
*pixDensity(2)
*pixelDensity(2)
*pixRes(2)
*pixelResolution(2)

At the moment, I'm in favor of pixelDensity(2)

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman Jun 8, 2015

Member

I vote pixelDensity()! I really like separating this out from size(). Since beginners begin with size() the less crazy/weird the docs page for that is the better. Also, now we've eliminated yet another place where JAVA2D appears!

This is not for the core API and I'm probably polluting this thread, but is there a way to do something like:

if (i'm on a high density display) {
  pixelDensity(2);
}

or no b/c of the whole settings() thing?

Member

shiffman commented Jun 8, 2015

I vote pixelDensity()! I really like separating this out from size(). Since beginners begin with size() the less crazy/weird the docs page for that is the better. Also, now we've eliminated yet another place where JAVA2D appears!

This is not for the core API and I'm probably polluting this thread, but is there a way to do something like:

if (i'm on a high density display) {
  pixelDensity(2);
}

or no b/c of the whole settings() thing?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

Yeah, that's another plus for making it a method. Right now it would be:

if (highResDisplay()) {
  pixelDensity(2);
}

but if we want this sort of use case, we probably need something like:

pixelDensity(displayDensity());

though that's not exactly self-explanatory.

Member

benfry commented Jun 8, 2015

Yeah, that's another plus for making it a method. Right now it would be:

if (highResDisplay()) {
  pixelDensity(2);
}

but if we want this sort of use case, we probably need something like:

pixelDensity(displayDensity());

though that's not exactly self-explanatory.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

Another plus for pixelDensity() is that this primarily affects how pixels behave—that they all change to 2x space. Certainly it looks nicer, but the pixel operations are where the weirdness happens.

Member

benfry commented Jun 8, 2015

Another plus for pixelDensity() is that this primarily affects how pixels behave—that they all change to 2x space. Certainly it looks nicer, but the pixel operations are where the weirdness happens.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

We could also reconsider splitting high res visuals from whether pixel operations go high res, but I think that's pretty awkward for images and other times we hit pixels. The plus here would be that we could always use retina when available, and people would only specify whether they wanted pixel operations (get/set/filter/copy/etc) to happen in the 2x space. But this all sounds very messy: in this scenario, a get(x, y, w, h) followed by a set() would make the image blurry, unless the 2x thing was set.

Member

benfry commented Jun 8, 2015

We could also reconsider splitting high res visuals from whether pixel operations go high res, but I think that's pretty awkward for images and other times we hit pixels. The plus here would be that we could always use retina when available, and people would only specify whether they wanted pixel operations (get/set/filter/copy/etc) to happen in the 2x space. But this all sounds very messy: in this scenario, a get(x, y, w, h) followed by a set() would make the image blurry, unless the 2x thing was set.

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman Jun 8, 2015

Member

I think that perhaps in the way that smooth() is now enabled by default, but wasn't in 1.0, since we haven't had a ton of retina testing that we should leave it off and require an explicit call to pixelDensity(). And then we'll turn it on by default and have a long github thread about what we're breaking for Processing 6.0.

Writing this I'm perhaps changing my mind in that would we want first-time users downloading Processing for a class on a retina machine to just automatically see the beauty of 2X?

@REAS will know just what to do.

Member

shiffman commented Jun 8, 2015

I think that perhaps in the way that smooth() is now enabled by default, but wasn't in 1.0, since we haven't had a ton of retina testing that we should leave it off and require an explicit call to pixelDensity(). And then we'll turn it on by default and have a long github thread about what we're breaking for Processing 6.0.

Writing this I'm perhaps changing my mind in that would we want first-time users downloading Processing for a class on a retina machine to just automatically see the beauty of 2X?

@REAS will know just what to do.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

The big problem with default 2x is actually the same as smoothing in 1.0... It looks much better (obviously) but it's a huge performance difference on older hardware. Newer hardware it's more negligible, but we have a lot of labs, schools, etc that are using machines that are 3 and 5 years old or more.

But as you say, thank god we have @REAS to sort this out.

Member

benfry commented Jun 8, 2015

The big problem with default 2x is actually the same as smoothing in 1.0... It looks much better (obviously) but it's a huge performance difference on older hardware. Newer hardware it's more negligible, but we have a lot of labs, schools, etc that are using machines that are 3 and 5 years old or more.

But as you say, thank god we have @REAS to sort this out.

@alignedleft

This comment has been minimized.

Show comment
Hide comment
@alignedleft

alignedleft Jun 8, 2015

Member

@REAS always knows.

For what it's worth, I also support using pixelDensity(). It seems like an elegant solution to the problem. pixelsDensity(2) works for "Retina" displays, and one can even crank up the density further for the super-ultra-retina displays of the future. (@shiffman: perhaps ITP needs a new "Tiny Pixels" initiative to complement Big Screens?) If not called, we can have smart default behavior.

Member

alignedleft commented Jun 8, 2015

@REAS always knows.

For what it's worth, I also support using pixelDensity(). It seems like an elegant solution to the problem. pixelsDensity(2) works for "Retina" displays, and one can even crank up the density further for the super-ultra-retina displays of the future. (@shiffman: perhaps ITP needs a new "Tiny Pixels" initiative to complement Big Screens?) If not called, we can have smart default behavior.

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Jun 8, 2015

Member

I have been thinking about what happens with old code. For example, I might have a piece of pre-3.0 code that I want to "just work" on a Retina display. Maybe this code uses images and maybe get(), set(), and pixels[]. I should be able to write pixelDensity(2) in my setup and the code behaves the same. The images won't be retina, but I think it's the right approach.

Maybe we also have imageDensity(2) to make it possible to work with images in High-DPI mode? I was trying to make this setting a part of imageMode(), but I haven't been able to get that to work in terms of logic.

This would mean to make a program that uses image fully High-DPI, it would need pixelDensity(2) and imageDensity(2) in setup()

Member

REAS commented Jun 8, 2015

I have been thinking about what happens with old code. For example, I might have a piece of pre-3.0 code that I want to "just work" on a Retina display. Maybe this code uses images and maybe get(), set(), and pixels[]. I should be able to write pixelDensity(2) in my setup and the code behaves the same. The images won't be retina, but I think it's the right approach.

Maybe we also have imageDensity(2) to make it possible to work with images in High-DPI mode? I was trying to make this setting a part of imageMode(), but I haven't been able to get that to work in terms of logic.

This would mean to make a program that uses image fully High-DPI, it would need pixelDensity(2) and imageDensity(2) in setup()

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

Ah yes... @REAS can you open an issue for the image issues? That's another fella that we should think through, i.e. do we need to have something where we magically load 2x versions of images, or do we simply call pixelDensity(2) on the image which will mean "I know this is 2x, draw it smaller".

For what it's worth, the pixelDensity() solution is now implemented in the source and feels good to me. Also removed the _2X versions of the renderers, all of which did nothing more than their superclasses than just calling pixelDensity = 2 in the constructor. That's been moved to PGraphics.setParent() where it belongs, and the density is picked up along with the smoothing settings.

Member

benfry commented Jun 8, 2015

Ah yes... @REAS can you open an issue for the image issues? That's another fella that we should think through, i.e. do we need to have something where we magically load 2x versions of images, or do we simply call pixelDensity(2) on the image which will mean "I know this is 2x, draw it smaller".

For what it's worth, the pixelDensity() solution is now implemented in the source and feels good to me. Also removed the _2X versions of the renderers, all of which did nothing more than their superclasses than just calling pixelDensity = 2 in the constructor. That's been moved to PGraphics.setParent() where it belongs, and the density is picked up along with the smoothing settings.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

Gonna close this, I think we're all on the same page. We can reopen if we need to revisit.

(I don't like to, but I'm locking this to avoid future comments/disagreements with this decision months from now, or unrelated bugs being appended here. If you have issues, please file something new and reference this item.)

Member

benfry commented Jun 8, 2015

Gonna close this, I think we're all on the same page. We can reopen if we need to revisit.

(I don't like to, but I'm locking this to avoid future comments/disagreements with this decision months from now, or unrelated bugs being appended here. If you have issues, please file something new and reference this item.)

@benfry benfry closed this Jun 8, 2015

@processing processing locked and limited conversation to collaborators Jun 8, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 8, 2015

Member

Ok, one last item for the docs: pixelDensity(2) should be called after size() or fullScreen() (or otherwise setting the display). It needs the display to be set before running so that it can put up a warning for people who try to do retina on non-retina devices.

Member

benfry commented Jun 8, 2015

Ok, one last item for the docs: pixelDensity(2) should be called after size() or fullScreen() (or otherwise setting the display). It needs the display to be set before running so that it can put up a warning for people who try to do retina on non-retina devices.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.