FX2D display is inverted in 3.0b6 #3795

Closed
monkstone opened this Issue Sep 13, 2015 · 17 comments

Comments

Projects
None yet
8 participants
@StanLepunK

This comment has been minimized.

Show comment
Hide comment
@StanLepunK

StanLepunK Sep 13, 2015

same on OSX 10.9.5

void setup() {
  size(300,300,FX2D) ;
}
void draw() {
  background(0) ;
  text("test",80,80) ;
}

same on OSX 10.9.5

void setup() {
  size(300,300,FX2D) ;
}
void draw() {
  background(0) ;
  text("test",80,80) ;
}
@jacbouzada

This comment has been minimized.

Show comment
Hide comment
@jacbouzada

jacbouzada Sep 13, 2015

Same problem in OS X 10.10.5

Same problem in OS X 10.10.5

@adegani

This comment has been minimized.

Show comment
Hide comment
@adegani

adegani Sep 13, 2015

Same problem (Linux). Processing-3.0b5 was OK!

adegani commented Sep 13, 2015

Same problem (Linux). Processing-3.0b5 was OK!

@benfry benfry changed the title from FX2D display is inverted in processing-3.0b6 (well on linux at least) to FX2D display is inverted in 3.0b6 Sep 14, 2015

@benfry benfry added the critical label Sep 14, 2015

@brendanmatkin

This comment has been minimized.

Show comment
Hide comment
@brendanmatkin

brendanmatkin Sep 14, 2015

confirm 10.10.5

confirm 10.10.5

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Sep 14, 2015

Contributor

For now, use noSmooth() in your setup() as a workaround. It looks like FX has buggy antialiasing in 8u60.

Contributor

JakubValtar commented Sep 14, 2015

For now, use noSmooth() in your setup() as a workaround. It looks like FX has buggy antialiasing in 8u60.

@JakubValtar JakubValtar added the known label Sep 14, 2015

@benfry benfry closed this in eeaa1c9 Sep 15, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 15, 2015

Member

Found a workaround for 3.0 beta 7.

Member

benfry commented Sep 15, 2015

Found a workaround for 3.0 beta 7.

@benfry benfry assigned benfry and unassigned JakubValtar Sep 15, 2015

@benfry benfry reopened this Sep 15, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 15, 2015

Member

Nuts... maybe not. Think I was fooled by this retina display.

Member

benfry commented Sep 15, 2015

Nuts... maybe not. Think I was fooled by this retina display.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 17, 2015

Member

So we can do one of the following:

  1. revert to the previous Java release before 8u60 (inconvenient for anyone building the source since they'll need to find/install an older Java release to build)
  2. leave this broken until it's fixed upstream in Java (but it's a nasty, obvious bug)
  3. check the Java version and do an axis flip if on OS X and Linux (need to make sure this would work and not introduce weirder off-by-1-pixel scenarios)
  4. disable smoothing when using 8u60 and OS X + Linux

Your vote, @JakubValtar?

Member

benfry commented Sep 17, 2015

So we can do one of the following:

  1. revert to the previous Java release before 8u60 (inconvenient for anyone building the source since they'll need to find/install an older Java release to build)
  2. leave this broken until it's fixed upstream in Java (but it's a nasty, obvious bug)
  3. check the Java version and do an axis flip if on OS X and Linux (need to make sure this would work and not introduce weirder off-by-1-pixel scenarios)
  4. disable smoothing when using 8u60 and OS X + Linux

Your vote, @JakubValtar?

@benfry benfry added this to the 3.0 final milestone Sep 17, 2015

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Sep 18, 2015

Contributor

I know you secretly wish we could get away with 2), I also do, but we are too nice for that. I would otherwise vote for 3), but I'm afraid it will be messy and people will break it (they always do). So, my proposal is:

We want most people to have antialiasing, so let's bundle 8u51 with the release so there is no compromise for majority of end users.

It also has to run on all recent JREs, so let's also disable smoothing for 8u60 + OS X & Linux combos and print warning that FX in 8u60 does not smooth if people try to enable it. And it's just a few lines of code so there is not much we can break. This covers developers & people who like to run sketches with different JREs (i.e. me & me). These people have enough knowledge to install 8u51 or switch renderer if they can't live without smoothing.

Contributor

JakubValtar commented Sep 18, 2015

I know you secretly wish we could get away with 2), I also do, but we are too nice for that. I would otherwise vote for 3), but I'm afraid it will be messy and people will break it (they always do). So, my proposal is:

We want most people to have antialiasing, so let's bundle 8u51 with the release so there is no compromise for majority of end users.

It also has to run on all recent JREs, so let's also disable smoothing for 8u60 + OS X & Linux combos and print warning that FX in 8u60 does not smooth if people try to enable it. And it's just a few lines of code so there is not much we can break. This covers developers & people who like to run sketches with different JREs (i.e. me & me). These people have enough knowledge to install 8u51 or switch renderer if they can't live without smoothing.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 18, 2015

Member

2 is the worst of the bunch, I think the third is cleanest/best if it actually works, followed by the fourth. Or maybe 4 and 1.

Member

benfry commented Sep 18, 2015

2 is the worst of the bunch, I think the third is cleanest/best if it actually works, followed by the fourth. Or maybe 4 and 1.

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Sep 18, 2015

Contributor

As I said, 3 will be messy and hard to get right and 4 alone has too broad impact. So I'm for 4+1 since 1 is really easy and will give smoothing to the masses and 4 covers devs.

(And I believe in case of 1 you can build with 8u60, but the ant script has to package in downloaded 8u51).

Contributor

JakubValtar commented Sep 18, 2015

As I said, 3 will be messy and hard to get right and 4 alone has too broad impact. So I'm for 4+1 since 1 is really easy and will give smoothing to the masses and 4 covers devs.

(And I believe in case of 1 you can build with 8u60, but the ant script has to package in downloaded 8u51).

@jacbouzada

This comment has been minimized.

Show comment
Hide comment
@jacbouzada

jacbouzada Sep 18, 2015

One vote for the 3rd option ;)
(but I don't know how messy/hard it would be....)

One vote for the 3rd option ;)
(but I don't know how messy/hard it would be....)

@benfry benfry closed this in 7ea1d25 Sep 18, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 18, 2015

Member

3 is too messy and will introduce more bugs than it fixes.

Going with 4 and 1 for the next release.

Member

benfry commented Sep 18, 2015

3 is too messy and will introduce more bugs than it fixes.

Going with 4 and 1 for the next release.

@tillnagel

This comment has been minimized.

Show comment
Hide comment
@tillnagel

tillnagel Sep 25, 2015

Just to let you know, I updated the Wiki page on how to build Processing to reflect this latest change. https://github.com/processing/processing/wiki/Build-Instructions

Just to let you know, I updated the Wiki page on how to build Processing to reflect this latest change. https://github.com/processing/processing/wiki/Build-Instructions

@monkstone

This comment has been minimized.

Show comment
Hide comment
@monkstone

monkstone Oct 21, 2015

Hi just to note @benfry problem does not seem to be resolved with recently released jdk1.8.0_66-b17

Hi just to note @benfry problem does not seem to be resolved with recently released jdk1.8.0_66-b17

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Oct 22, 2015

Member

Yep, I don't expect it until 8u80.

Member

benfry commented Oct 22, 2015

Yep, I don't expect it until 8u80.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Feb 13, 2016

Member

Fixed in 8u72, and Processing 3.0.2 will ship with 8u74 so we're all set on this one.

Member

benfry commented Feb 13, 2016

Fixed in 8u72, and Processing 3.0.2 will ship with 8u74 so we're all set on this one.

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