From yuri.nesterenko at oracle.com Mon Dec 2 14:07:53 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Mon, 02 Dec 2013 18:07:53 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup Message-ID: <529C9439.7020202@oracle.com> Colleagues, please review this yet another cleanup request. They will never end but then again, they are easy to review. Here's the webrev: http://cr.openjdk.java.net/~yan/8029264/webrev.00 Bug is: https://bugs.openjdk.java.net/browse/JDK-8029264 My routine was: increase number of allowed warnings/errors; enable doclint. make all docs > log 2>&1 Pick up swing files to clean. Clean, running DocLint on them repeatedly, until I only have unfixable (for now) issues. make all docs > log 2>&1 Pick up swing HTML files related to my original list, run tidy -e on them. Repeat the cleanup. As a result, no real code, animal, or plant was harmed. Some doc issues were eliminated. Tidy is happy with resulting HTML; the only doclint criteria still violated require CCC or convention changes. If you are interested in checking doclint output, try $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java Thanks, -yan From yuri.nesterenko at oracle.com Wed Dec 4 07:47:50 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 04 Dec 2013 11:47:50 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup In-Reply-To: <529C9439.7020202@oracle.com> References: <529C9439.7020202@oracle.com> Message-ID: <529EDE26.4000402@oracle.com> One more time! Please take a look. Mailing list is a lousy tool for review requests like this. Thanks, -yan On 12/02/2013 06:07 PM, Yuri Nesterenko wrote: > Colleagues, > > please review this yet another cleanup request. > They will never end but then again, they are easy to review. > > Here's the webrev: > http://cr.openjdk.java.net/~yan/8029264/webrev.00 > Bug is: > https://bugs.openjdk.java.net/browse/JDK-8029264 > > My routine was: > > increase number of allowed warnings/errors; enable doclint. > make all docs > log 2>&1 > Pick up swing files to clean. > > Clean, running DocLint on them repeatedly, until I only have unfixable > (for now) issues. > make all docs > log 2>&1 > Pick up swing HTML files related to my original list, > run tidy -e on them. > Repeat the cleanup. > > As a result, no real code, animal, or plant was harmed. > Some doc issues were eliminated. > Tidy is happy with resulting HTML; the only doclint criteria > still violated require CCC or convention changes. > > If you are interested in checking doclint output, try > > $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ > com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java > > Thanks, > -yan From alexandr.scherbatiy at oracle.com Wed Dec 4 12:47:21 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 04 Dec 2013 16:47:21 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup In-Reply-To: <529EDE26.4000402@oracle.com> References: <529C9439.7020202@oracle.com> <529EDE26.4000402@oracle.com> Message-ID: <529F2459.5000206@oracle.com> There is the definition of the JDK 1.5 tags: http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/whatsnew-1.5.0.html#tags The {@literal} tag denotes literal text. The enclosed text is interpreted as not containing HTML markup or nested javadoc tags. For example, the doc comment text: {@literal ac} displays in the generated HTML page unchanged: ac -- that is, the is not interpreted as bold. The {@code} tag formats literal text in the code font. It is equivalent to {@literal}. JOptionPane.java - * centered on the screen (depending on the L&F). + * centered on the screen (depending on the {@code L&F}). It seems that it is better to use the literal tag here. RowFilter.java - * columns are < 0. + * columns are < 0. The literal tag can be used here also. Thanks, Alexandr. On 12/4/2013 11:47 AM, Yuri Nesterenko wrote: > One more time! Please take a look. > > Mailing list is a lousy tool for review requests like this. > > Thanks, > -yan > > On 12/02/2013 06:07 PM, Yuri Nesterenko wrote: >> Colleagues, >> >> please review this yet another cleanup request. >> They will never end but then again, they are easy to review. >> >> Here's the webrev: >> http://cr.openjdk.java.net/~yan/8029264/webrev.00 >> Bug is: >> https://bugs.openjdk.java.net/browse/JDK-8029264 >> >> My routine was: >> >> increase number of allowed warnings/errors; enable doclint. >> make all docs > log 2>&1 >> Pick up swing files to clean. >> >> Clean, running DocLint on them repeatedly, until I only have unfixable >> (for now) issues. >> make all docs > log 2>&1 >> Pick up swing HTML files related to my original list, >> run tidy -e on them. >> Repeat the cleanup. >> >> As a result, no real code, animal, or plant was harmed. >> Some doc issues were eliminated. >> Tidy is happy with resulting HTML; the only doclint criteria >> still violated require CCC or convention changes. >> >> If you are interested in checking doclint output, try >> >> $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ >> com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java >> >> Thanks, >> -yan > From yuri.nesterenko at oracle.com Wed Dec 4 12:58:56 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 04 Dec 2013 16:58:56 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup In-Reply-To: <529F2459.5000206@oracle.com> References: <529C9439.7020202@oracle.com> <529EDE26.4000402@oracle.com> <529F2459.5000206@oracle.com> Message-ID: <529F2710.8050500@oracle.com> Thank you Alexandr, I'll change that and submit a new webrev but I hope you'll review it again pretty soon! It would require RT authorization though, anyway, anything ready after 22:00 MSK tonight. -yan On 12/04/2013 04:47 PM, Alexander Scherbatiy wrote: > > There is the definition of the JDK 1.5 tags: > http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/whatsnew-1.5.0.html#tags > > > The {@literal} tag denotes literal text. The enclosed text is > interpreted as not containing HTML markup or nested javadoc tags. For > example, the doc comment text: {@literal ac} > displays in the generated HTML page unchanged: ac -- that is, > the is not interpreted as bold. > The {@code} tag formats literal text in the code font. It is > equivalent to {@literal}. > > JOptionPane.java > - * centered on the screen (depending on the L&F). > + * centered on the screen (depending on the {@code L&F}). > It seems that it is better to use the literal tag here. > > > RowFilter.java > - * columns are < 0. > + * columns are < 0. > The literal tag can be used here also. > > Thanks, > Alexandr. > > > On 12/4/2013 11:47 AM, Yuri Nesterenko wrote: >> One more time! Please take a look. >> >> Mailing list is a lousy tool for review requests like this. >> >> Thanks, >> -yan >> >> On 12/02/2013 06:07 PM, Yuri Nesterenko wrote: >>> Colleagues, >>> >>> please review this yet another cleanup request. >>> They will never end but then again, they are easy to review. >>> >>> Here's the webrev: >>> http://cr.openjdk.java.net/~yan/8029264/webrev.00 >>> Bug is: >>> https://bugs.openjdk.java.net/browse/JDK-8029264 >>> >>> My routine was: >>> >>> increase number of allowed warnings/errors; enable doclint. >>> make all docs > log 2>&1 >>> Pick up swing files to clean. >>> >>> Clean, running DocLint on them repeatedly, until I only have unfixable >>> (for now) issues. >>> make all docs > log 2>&1 >>> Pick up swing HTML files related to my original list, >>> run tidy -e on them. >>> Repeat the cleanup. >>> >>> As a result, no real code, animal, or plant was harmed. >>> Some doc issues were eliminated. >>> Tidy is happy with resulting HTML; the only doclint criteria >>> still violated require CCC or convention changes. >>> >>> If you are interested in checking doclint output, try >>> >>> $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ >>> com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java >>> >>> Thanks, >>> -yan >> > From yuri.nesterenko at oracle.com Wed Dec 4 14:24:37 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 04 Dec 2013 18:24:37 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup In-Reply-To: <529F2459.5000206@oracle.com> References: <529C9439.7020202@oracle.com> <529EDE26.4000402@oracle.com> <529F2459.5000206@oracle.com> Message-ID: <529F3B25.1060603@oracle.com> Colleagues, Please review another version of the fix. Here's the webrev: http://cr.openjdk.java.net/~yan/8029264/webrev.01 Bug is: https://bugs.openjdk.java.net/browse/JDK-8029264 Here, @code changed to @literal in certain places and < and > changed (in my changes but not elsewhere) to {@literal <} and {@literal >} corresp. I didn't change ≥ and ≤ though: I swear they look much better than @literal variants, and even easier to read. Thanks, -yan On 12/04/2013 04:47 PM, Alexander Scherbatiy wrote: > > There is the definition of the JDK 1.5 tags: > http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/whatsnew-1.5.0.html#tags > > > The {@literal} tag denotes literal text. The enclosed text is > interpreted as not containing HTML markup or nested javadoc tags. For > example, the doc comment text: {@literal ac} > displays in the generated HTML page unchanged: ac -- that is, > the is not interpreted as bold. > The {@code} tag formats literal text in the code font. It is > equivalent to {@literal}. > > JOptionPane.java > - * centered on the screen (depending on the L&F). > + * centered on the screen (depending on the {@code L&F}). > It seems that it is better to use the literal tag here. > > > RowFilter.java > - * columns are < 0. > + * columns are < 0. > The literal tag can be used here also. > > Thanks, > Alexandr. > > > On 12/4/2013 11:47 AM, Yuri Nesterenko wrote: >> One more time! Please take a look. >> >> Mailing list is a lousy tool for review requests like this. >> >> Thanks, >> -yan >> >> On 12/02/2013 06:07 PM, Yuri Nesterenko wrote: >>> Colleagues, >>> >>> please review this yet another cleanup request. >>> They will never end but then again, they are easy to review. >>> >>> Here's the webrev: >>> http://cr.openjdk.java.net/~yan/8029264/webrev.00 >>> Bug is: >>> https://bugs.openjdk.java.net/browse/JDK-8029264 >>> >>> My routine was: >>> >>> increase number of allowed warnings/errors; enable doclint. >>> make all docs > log 2>&1 >>> Pick up swing files to clean. >>> >>> Clean, running DocLint on them repeatedly, until I only have unfixable >>> (for now) issues. >>> make all docs > log 2>&1 >>> Pick up swing HTML files related to my original list, >>> run tidy -e on them. >>> Repeat the cleanup. >>> >>> As a result, no real code, animal, or plant was harmed. >>> Some doc issues were eliminated. >>> Tidy is happy with resulting HTML; the only doclint criteria >>> still violated require CCC or convention changes. >>> >>> If you are interested in checking doclint output, try >>> >>> $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ >>> com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java >>> >>> Thanks, >>> -yan >> > From alexandr.scherbatiy at oracle.com Wed Dec 4 14:45:29 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 04 Dec 2013 18:45:29 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup In-Reply-To: <529F3B25.1060603@oracle.com> References: <529C9439.7020202@oracle.com> <529EDE26.4000402@oracle.com> <529F2459.5000206@oracle.com> <529F3B25.1060603@oracle.com> Message-ID: <529F4009.5060802@oracle.com> The fix looks good for me. Thanks, Alexandr. On 12/4/2013 6:24 PM, Yuri Nesterenko wrote: > Colleagues, > > > Please review another version of the fix. > Here's the webrev: > http://cr.openjdk.java.net/~yan/8029264/webrev.01 > Bug is: > https://bugs.openjdk.java.net/browse/JDK-8029264 > > > Here, @code changed to @literal > in certain places and < and > changed (in my changes but not > elsewhere) to {@literal <} and {@literal >} corresp. > > I didn't change ≥ and ≤ though: I swear they look much better > than @literal variants, and even easier to read. > > > Thanks, > -yan > > On 12/04/2013 04:47 PM, Alexander Scherbatiy wrote: >> >> There is the definition of the JDK 1.5 tags: >> http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/whatsnew-1.5.0.html#tags >> >> >> >> The {@literal} tag denotes literal text. The enclosed text is >> interpreted as not containing HTML markup or nested javadoc tags. For >> example, the doc comment text: {@literal ac} >> displays in the generated HTML page unchanged: ac -- that is, >> the is not interpreted as bold. >> The {@code} tag formats literal text in the code font. It is >> equivalent to {@literal}. >> >> JOptionPane.java >> - * centered on the screen (depending on the L&F). >> + * centered on the screen (depending on the {@code L&F}). >> It seems that it is better to use the literal tag here. >> >> >> RowFilter.java >> - * columns are < 0. >> + * columns are < 0. >> The literal tag can be used here also. >> >> Thanks, >> Alexandr. >> >> >> On 12/4/2013 11:47 AM, Yuri Nesterenko wrote: >>> One more time! Please take a look. >>> >>> Mailing list is a lousy tool for review requests like this. >>> >>> Thanks, >>> -yan >>> >>> On 12/02/2013 06:07 PM, Yuri Nesterenko wrote: >>>> Colleagues, >>>> >>>> please review this yet another cleanup request. >>>> They will never end but then again, they are easy to review. >>>> >>>> Here's the webrev: >>>> http://cr.openjdk.java.net/~yan/8029264/webrev.00 >>>> Bug is: >>>> https://bugs.openjdk.java.net/browse/JDK-8029264 >>>> >>>> My routine was: >>>> >>>> increase number of allowed warnings/errors; enable doclint. >>>> make all docs > log 2>&1 >>>> Pick up swing files to clean. >>>> >>>> Clean, running DocLint on them repeatedly, until I only have unfixable >>>> (for now) issues. >>>> make all docs > log 2>&1 >>>> Pick up swing HTML files related to my original list, >>>> run tidy -e on them. >>>> Repeat the cleanup. >>>> >>>> As a result, no real code, animal, or plant was harmed. >>>> Some doc issues were eliminated. >>>> Tidy is happy with resulting HTML; the only doclint criteria >>>> still violated require CCC or convention changes. >>>> >>>> If you are interested in checking doclint output, try >>>> >>>> $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ >>>> com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java >>>> >>>> Thanks, >>>> -yan >>> >> > From Sergey.Bylokhov at oracle.com Thu Dec 5 13:17:26 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 05 Dec 2013 17:17:26 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup In-Reply-To: <529F4009.5060802@oracle.com> References: <529C9439.7020202@oracle.com> <529EDE26.4000402@oracle.com> <529F2459.5000206@oracle.com> <529F3B25.1060603@oracle.com> <529F4009.5060802@oracle.com> Message-ID: <52A07CE6.6030600@oracle.com> The fix looks good. On 12/4/13 6:45 PM, Alexander Scherbatiy wrote: > > The fix looks good for me. > > Thanks, > Alexandr. > > On 12/4/2013 6:24 PM, Yuri Nesterenko wrote: >> Colleagues, >> >> >> Please review another version of the fix. >> Here's the webrev: >> http://cr.openjdk.java.net/~yan/8029264/webrev.01 >> Bug is: >> https://bugs.openjdk.java.net/browse/JDK-8029264 >> >> >> Here, @code changed to @literal >> in certain places and < and > changed (in my changes but not >> elsewhere) to {@literal <} and {@literal >} corresp. >> >> I didn't change ≥ and ≤ though: I swear they look much better >> than @literal variants, and even easier to read. >> >> >> Thanks, >> -yan >> >> On 12/04/2013 04:47 PM, Alexander Scherbatiy wrote: >>> >>> There is the definition of the JDK 1.5 tags: >>> http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/whatsnew-1.5.0.html#tags >>> >>> >>> >>> The {@literal} tag denotes literal text. The enclosed text is >>> interpreted as not containing HTML markup or nested javadoc tags. For >>> example, the doc comment text: {@literal ac} >>> displays in the generated HTML page unchanged: ac -- that is, >>> the is not interpreted as bold. >>> The {@code} tag formats literal text in the code font. It is >>> equivalent to {@literal}. >>> >>> JOptionPane.java >>> - * centered on the screen (depending on the L&F). >>> + * centered on the screen (depending on the {@code L&F}). >>> It seems that it is better to use the literal tag here. >>> >>> >>> RowFilter.java >>> - * columns are < 0. >>> + * columns are < 0. >>> The literal tag can be used here also. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 12/4/2013 11:47 AM, Yuri Nesterenko wrote: >>>> One more time! Please take a look. >>>> >>>> Mailing list is a lousy tool for review requests like this. >>>> >>>> Thanks, >>>> -yan >>>> >>>> On 12/02/2013 06:07 PM, Yuri Nesterenko wrote: >>>>> Colleagues, >>>>> >>>>> please review this yet another cleanup request. >>>>> They will never end but then again, they are easy to review. >>>>> >>>>> Here's the webrev: >>>>> http://cr.openjdk.java.net/~yan/8029264/webrev.00 >>>>> Bug is: >>>>> https://bugs.openjdk.java.net/browse/JDK-8029264 >>>>> >>>>> My routine was: >>>>> >>>>> increase number of allowed warnings/errors; enable doclint. >>>>> make all docs > log 2>&1 >>>>> Pick up swing files to clean. >>>>> >>>>> Clean, running DocLint on them repeatedly, until I only have >>>>> unfixable >>>>> (for now) issues. >>>>> make all docs > log 2>&1 >>>>> Pick up swing HTML files related to my original list, >>>>> run tidy -e on them. >>>>> Repeat the cleanup. >>>>> >>>>> As a result, no real code, animal, or plant was harmed. >>>>> Some doc issues were eliminated. >>>>> Tidy is happy with resulting HTML; the only doclint criteria >>>>> still violated require CCC or convention changes. >>>>> >>>>> If you are interested in checking doclint output, try >>>>> >>>>> $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ >>>>> com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java >>>>> >>>>> Thanks, >>>>> -yan >>>> >>> >> > -- Best regards, Sergey. From sergey.malenkov at oracle.com Thu Dec 5 13:20:39 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Thu, 05 Dec 2013 17:20:39 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup In-Reply-To: <529F4009.5060802@oracle.com> References: <529C9439.7020202@oracle.com> <529EDE26.4000402@oracle.com> <529F2459.5000206@oracle.com> <529F3B25.1060603@oracle.com> <529F4009.5060802@oracle.com> Message-ID: <52A07DA7.6090504@oracle.com> The fix look OK for me too. SAM On 04.12.2013 18:45, Alexander Scherbatiy wrote: > > The fix looks good for me. > > Thanks, > Alexandr. > > On 12/4/2013 6:24 PM, Yuri Nesterenko wrote: >> Colleagues, >> >> >> Please review another version of the fix. >> Here's the webrev: >> http://cr.openjdk.java.net/~yan/8029264/webrev.01 >> Bug is: >> https://bugs.openjdk.java.net/browse/JDK-8029264 >> >> >> Here, @code changed to @literal >> in certain places and < and > changed (in my changes but not >> elsewhere) to {@literal <} and {@literal >} corresp. >> >> I didn't change ≥ and ≤ though: I swear they look much better >> than @literal variants, and even easier to read. >> >> >> Thanks, >> -yan >> >> On 12/04/2013 04:47 PM, Alexander Scherbatiy wrote: >>> >>> There is the definition of the JDK 1.5 tags: >>> http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/whatsnew-1.5.0.html#tags >>> >>> >>> >>> The {@literal} tag denotes literal text. The enclosed text is >>> interpreted as not containing HTML markup or nested javadoc tags. For >>> example, the doc comment text: {@literal ac} >>> displays in the generated HTML page unchanged: ac -- that is, >>> the is not interpreted as bold. >>> The {@code} tag formats literal text in the code font. It is >>> equivalent to {@literal}. >>> >>> JOptionPane.java >>> - * centered on the screen (depending on the L&F). >>> + * centered on the screen (depending on the {@code L&F}). >>> It seems that it is better to use the literal tag here. >>> >>> >>> RowFilter.java >>> - * columns are < 0. >>> + * columns are < 0. >>> The literal tag can be used here also. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 12/4/2013 11:47 AM, Yuri Nesterenko wrote: >>>> One more time! Please take a look. >>>> >>>> Mailing list is a lousy tool for review requests like this. >>>> >>>> Thanks, >>>> -yan >>>> >>>> On 12/02/2013 06:07 PM, Yuri Nesterenko wrote: >>>>> Colleagues, >>>>> >>>>> please review this yet another cleanup request. >>>>> They will never end but then again, they are easy to review. >>>>> >>>>> Here's the webrev: >>>>> http://cr.openjdk.java.net/~yan/8029264/webrev.00 >>>>> Bug is: >>>>> https://bugs.openjdk.java.net/browse/JDK-8029264 >>>>> >>>>> My routine was: >>>>> >>>>> increase number of allowed warnings/errors; enable doclint. >>>>> make all docs > log 2>&1 >>>>> Pick up swing files to clean. >>>>> >>>>> Clean, running DocLint on them repeatedly, until I only have >>>>> unfixable >>>>> (for now) issues. >>>>> make all docs > log 2>&1 >>>>> Pick up swing HTML files related to my original list, >>>>> run tidy -e on them. >>>>> Repeat the cleanup. >>>>> >>>>> As a result, no real code, animal, or plant was harmed. >>>>> Some doc issues were eliminated. >>>>> Tidy is happy with resulting HTML; the only doclint criteria >>>>> still violated require CCC or convention changes. >>>>> >>>>> If you are interested in checking doclint output, try >>>>> >>>>> $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ >>>>> com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java >>>>> >>>>> Thanks, >>>>> -yan >>>> >>> >> > From yuri.nesterenko at oracle.com Thu Dec 5 13:27:47 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 05 Dec 2013 17:27:47 +0400 Subject: [8] Review Request: 8029264 [doclint] more doclint and tidy cleanup In-Reply-To: <52A07DA7.6090504@oracle.com> References: <529C9439.7020202@oracle.com> <529EDE26.4000402@oracle.com> <529F2459.5000206@oracle.com> <529F3B25.1060603@oracle.com> <529F4009.5060802@oracle.com> <52A07DA7.6090504@oracle.com> Message-ID: <52A07F53.2000207@oracle.com> Thank you guys! -yan On 12/05/2013 05:20 PM, sergey malenkov wrote: > The fix look OK for me too. > > SAM > > On 04.12.2013 18:45, Alexander Scherbatiy wrote: >> >> The fix looks good for me. >> >> Thanks, >> Alexandr. >> >> On 12/4/2013 6:24 PM, Yuri Nesterenko wrote: >>> Colleagues, >>> >>> >>> Please review another version of the fix. >>> Here's the webrev: >>> http://cr.openjdk.java.net/~yan/8029264/webrev.01 >>> Bug is: >>> https://bugs.openjdk.java.net/browse/JDK-8029264 >>> >>> >>> Here, @code changed to @literal >>> in certain places and < and > changed (in my changes but not >>> elsewhere) to {@literal <} and {@literal >} corresp. >>> >>> I didn't change ≥ and ≤ though: I swear they look much better >>> than @literal variants, and even easier to read. >>> >>> >>> Thanks, >>> -yan >>> >>> On 12/04/2013 04:47 PM, Alexander Scherbatiy wrote: >>>> >>>> There is the definition of the JDK 1.5 tags: >>>> http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/whatsnew-1.5.0.html#tags >>>> >>>> >>>> >>>> The {@literal} tag denotes literal text. The enclosed text is >>>> interpreted as not containing HTML markup or nested javadoc tags. For >>>> example, the doc comment text: {@literal ac} >>>> displays in the generated HTML page unchanged: ac -- that is, >>>> the is not interpreted as bold. >>>> The {@code} tag formats literal text in the code font. It is >>>> equivalent to {@literal}. >>>> >>>> JOptionPane.java >>>> - * centered on the screen (depending on the L&F). >>>> + * centered on the screen (depending on the {@code L&F}). >>>> It seems that it is better to use the literal tag here. >>>> >>>> >>>> RowFilter.java >>>> - * columns are < 0. >>>> + * columns are < 0. >>>> The literal tag can be used here also. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> On 12/4/2013 11:47 AM, Yuri Nesterenko wrote: >>>>> One more time! Please take a look. >>>>> >>>>> Mailing list is a lousy tool for review requests like this. >>>>> >>>>> Thanks, >>>>> -yan >>>>> >>>>> On 12/02/2013 06:07 PM, Yuri Nesterenko wrote: >>>>>> Colleagues, >>>>>> >>>>>> please review this yet another cleanup request. >>>>>> They will never end but then again, they are easy to review. >>>>>> >>>>>> Here's the webrev: >>>>>> http://cr.openjdk.java.net/~yan/8029264/webrev.00 >>>>>> Bug is: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8029264 >>>>>> >>>>>> My routine was: >>>>>> >>>>>> increase number of allowed warnings/errors; enable doclint. >>>>>> make all docs > log 2>&1 >>>>>> Pick up swing files to clean. >>>>>> >>>>>> Clean, running DocLint on them repeatedly, until I only have >>>>>> unfixable >>>>>> (for now) issues. >>>>>> make all docs > log 2>&1 >>>>>> Pick up swing HTML files related to my original list, >>>>>> run tidy -e on them. >>>>>> Repeat the cleanup. >>>>>> >>>>>> As a result, no real code, animal, or plant was harmed. >>>>>> Some doc issues were eliminated. >>>>>> Tidy is happy with resulting HTML; the only doclint criteria >>>>>> still violated require CCC or convention changes. >>>>>> >>>>>> If you are interested in checking doclint output, try >>>>>> >>>>>> $JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \ >>>>>> com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java >>>>>> >>>>>> Thanks, >>>>>> -yan >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Dec 9 14:24:33 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 09 Dec 2013 18:24:33 +0400 Subject: Result: New Swing Group Member: Petr Pchelko Message-ID: <52A5D2A1.1070707@oracle.com> The vote for Petr Pchelko [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Alexandr. [1] http://mail.openjdk.java.net/pipermail/swing-dev/2013-November/003140.html [2] http://openjdk.java.net/bylaws#lazy-consensus From volker.simonis at gmail.com Mon Dec 9 18:49:13 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 9 Dec 2013 19:49:13 +0100 Subject: Regression test for 8016551 on Linux/Unix Message-ID: Hi Leonid, could you please explain, how the regression test you've added for 8016551 is supposed to work? If I run this test standalone or within JTreg with '-othervm' option on Linux the test displays a frame with the close icon and then it throws an sun.awt.SunToolkit$OperationTimedOut() exception because of the call to SunToolkit.realSync(): Exception in thread "main" sun.awt.SunToolkit$OperationTimedOut: 10001 at sun.awt.X11.XToolkit.syncNativeQueue(XToolkit.java:2427) at sun.awt.SunToolkit.realSync(SunToolkit.java:1501) at bug8016551.main(bug8016551.java:40) Within JTreg, this of course makes the test fail. If running standalone, the frame will be still displayed until I close the window. If I run the test within JTreg with the '-agentvm' option, it is even not possible to call setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) on the created frame, because agent-VMs run with a SecurityManager which forbids this (also see my mail to http://mail.openjdk.java.net/pipermail/quality-discuss/2013-December/000175.html): ----------System.err:(33/2049)---------- java.lang.reflect.InvocationTargetException at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300) at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350) at bug8016551.main(bug8016551.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.SecurityException: System.exit() forbidden by JT Harness at com.sun.javatest.JavaTestSecurityManager.checkExit(JavaTestSecurityManager.java:117) at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:395) at bug8016551$1.run(bug8016551.java:57) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) So I wonder how this test is supposed to work? Who will actually close the created frame? Or is this supposed to be a manual test? Thank you and best regards, Volker From Sergey.Bylokhov at oracle.com Mon Dec 9 21:09:36 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Dec 2013 01:09:36 +0400 Subject: Regression test for 8016551 on Linux/Unix In-Reply-To: References: Message-ID: <52A63190.2050003@oracle.com> Hi, Volker. On 09.12.2013 22:49, Volker Simonis wrote: > If I run this test standalone or within JTreg with '-othervm' option > on Linux the test displays a frame with the close icon and then it > throws an sun.awt.SunToolkit$OperationTimedOut() exception because of > the call to SunToolkit.realSync(): > > Exception in thread "main" sun.awt.SunToolkit$OperationTimedOut: 10001 > at sun.awt.X11.XToolkit.syncNativeQueue(XToolkit.java:2427) > at sun.awt.SunToolkit.realSync(SunToolkit.java:1501) > at bug8016551.main(bug8016551.java:40) What's a bug. This code should not fail. What window manager did you use? > Within JTreg, this of course makes the test fail. Sure, because a test throw an exception. I guess it will pass, if you change SunToolkit.realSync() to the Thread.sleep() for example. > If running > standalone, the frame will be still displayed until I close the > window. > > > So I wonder how this test is supposed to work? Who will actually close > the created frame? Or is this supposed to be a manual test? It should be closed by the jtreg, if main() method is ended without exception. It will be good to add a dispose at the end of the test, but anyway the problem here is in realSync(). > > Thank you and best regards, > Volker -- Best regards, Sergey. From volker.simonis at gmail.com Mon Dec 9 21:49:55 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 9 Dec 2013 22:49:55 +0100 Subject: Regression test for 8016551 on Linux/Unix In-Reply-To: <52A63190.2050003@oracle.com> References: <52A63190.2050003@oracle.com> Message-ID: On Monday, December 9, 2013, Sergey Bylokhov wrote: > Hi, Volker. > On 09.12.2013 22:49, Volker Simonis wrote: > >> If I run this test standalone or within JTreg with '-othervm' option >> on Linux the test displays a frame with the close icon and then it >> throws an sun.awt.SunToolkit$OperationTimedOut() exception because of >> the call to SunToolkit.realSync(): >> >> Exception in thread "main" sun.awt.SunToolkit$OperationTimedOut: 10001 >> at sun.awt.X11.XToolkit.syncNativeQueue(XToolkit.java:2427) >> at sun.awt.SunToolkit.realSync(SunToolkit.java:1501) >> at bug8016551.main(bug8016551.java:40) >> > What's a bug. This code should not fail. What window manager did you use? I use xfce with ubuntu 12.04. I can try different ones tomorrow if you think it is related to the window manager. > Within JTreg, this of course makes the test fail. >> > Sure, because a test throw an exception. I guess it will pass, if you > change SunToolkit.realSync() to the Thread.sleep() for example. > >> If running >> standalone, the frame will be still displayed until I close the >> window. >> >> >> So I wonder how this test is supposed to work? Who will actually close >> the created frame? Or is this supposed to be a manual test? >> > It should be closed by the jtreg, if main() method is ended without > exception. > It will be good to add a dispose at the end of the test, but anyway the > problem here is in realSync(). OK, I'll try both, adding dispose and replacing realSync by Thread.sleep. But what about the security exception from the JavaTestSecurityManager when calling setDefaultCloseOperation on JFrame. Don't you see it? And if not, what exact version of jtreg/jtharness do you use? Thank you and best regards, Volker >> Thank you and best regards, >> Volker >> > > > -- > Best regards, Sergey. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.romanov at oracle.com Tue Dec 10 01:15:58 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 10 Dec 2013 05:15:58 +0400 Subject: Regression test for 8016551 on Linux/Unix In-Reply-To: References: <52A63190.2050003@oracle.com> Message-ID: On Dec 10, 2013, at 1:49 AM, Volker Simonis wrote: > > > On Monday, December 9, 2013, Sergey Bylokhov wrote: > Hi, Volker. > On 09.12.2013 22:49, Volker Simonis wrote: > If I run this test standalone or within JTreg with '-othervm' option > on Linux the test displays a frame with the close icon and then it > throws an sun.awt.SunToolkit$OperationTimedOut() exception because of > the call to SunToolkit.realSync(): > > Exception in thread "main" sun.awt.SunToolkit$OperationTimedOut: 10001 > at sun.awt.X11.XToolkit.syncNativeQueue(XToolkit.java:2427) > at sun.awt.SunToolkit.realSync(SunToolkit.java:1501) > at bug8016551.main(bug8016551.java:40) > What's a bug. This code should not fail. What window manager did you use? > > I use xfce with ubuntu 12.04. I can try different ones tomorrow if you think it is related to the window manager. Ah, I see? This is a known problem: https://bugs.openjdk.java.net/browse/JDK-7033533 Regards, Leonid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Dec 10 10:54:50 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 10 Dec 2013 11:54:50 +0100 Subject: Regression test for 8016551 on Linux/Unix In-Reply-To: References: <52A63190.2050003@oracle.com> Message-ID: Hi Leonid, thanks for the link. Yes, this was indeed one of my problems. The test runs in VNC with twm and even without any window manager. However I still can not run the test in agentvm mode because of the security exception when setting the default close option: ----------System.err:(33/2049)---------- java.lang.reflect.InvocationTargetException at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300) at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350) at bug8016551.main(bug8016551.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.SecurityException: System.exit() forbidden by JT Harness at com.sun.javatest.JavaTestSecurityManager.checkExit(JavaTestSecurityManager.java:117) at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:395) at bug8016551$1.run(bug8016551.java:57) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) Any idea why this happens? It only happens for this specific test - all other jdk tests look good now (i.e. 4653 psassed, 6 failed). It's strange, because the agent VM is running with -Djava.security.policy=file:/tmp/JTwork/jtreg.policy and the policy file contains: grant codebase "file:/share/software/Java/JTREG_from_source/jtreg/build/images/jtreg/lib/jtreg.jar" { permission java.security.AllPermission; }; grant codebase "file:/share/software/Java/JTREG_from_source/jtreg/build/images/jtreg/lib/javatest.jar" { permission java.security.AllPermission; }; Maybe a problem of jtreg/jtharness? Which versions of jtreg/jtharness do you use? Thank you and best regards, Volker On Tue, Dec 10, 2013 at 2:15 AM, Leonid Romanov wrote: > > On Dec 10, 2013, at 1:49 AM, Volker Simonis > wrote: > > > > On Monday, December 9, 2013, Sergey Bylokhov wrote: >> >> Hi, Volker. >> On 09.12.2013 22:49, Volker Simonis wrote: >>> >>> If I run this test standalone or within JTreg with '-othervm' option >>> on Linux the test displays a frame with the close icon and then it >>> throws an sun.awt.SunToolkit$OperationTimedOut() exception because of >>> the call to SunToolkit.realSync(): >>> >>> Exception in thread "main" sun.awt.SunToolkit$OperationTimedOut: 10001 >>> at sun.awt.X11.XToolkit.syncNativeQueue(XToolkit.java:2427) >>> at sun.awt.SunToolkit.realSync(SunToolkit.java:1501) >>> at bug8016551.main(bug8016551.java:40) >> >> What's a bug. This code should not fail. What window manager did you use? > > > I use xfce with ubuntu 12.04. I can try different ones tomorrow if you think > it is related to the window manager. > > > Ah, I see? This is a known problem: > https://bugs.openjdk.java.net/browse/JDK-7033533 > > Regards, > Leonid. From anthony.petrov at oracle.com Tue Dec 10 19:57:37 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Dec 2013 23:57:37 +0400 Subject: [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52A723B8.7090705@oracle.com> References: <52A723B8.7090705@oracle.com> Message-ID: <52A77231.1030902@oracle.com> Hi Anton, I'm not an expert in HiDPI rendering, so I'll defer to Jim and Sergey to comment on the core changes. I still have a few comments regarding the fix: 1. src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java > 265 contentView.initialize(peer, null); Are you sure calling view.initialize() from CPW.initializeBase() doesn't introduce any unwanted side-effects? Interestingly, the contentView field gets re-written and re-initialized in the CPW.initialize() method after calling the initializeBase(). Seems very strange to me. 2. I'm not sure if adding the scale field to the BI is a good idea. I think that the image shouldn't be aware of any scale. After all, it's just an image, a bitmap. It has its real dimensions corresponding to the actual size of the image stored in RAM. Whether this image is going to be represented as a scaled image is something that a code that uses the image should be concerned with, not the image itself. 3. src/share/classes/java/awt/peer/FramePeer.java > 139 default void notifyScaleFactorChanged() {} I think this deserves to be declared in WindowPeer so that we could use it w/o additional modifications in the future if we add support for public notifications about the scale factor changes. 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in the JViewport class and other Swing classes. -- best regards, Anthony On 12/10/2013 06:22 PM, Anton V. Tarasov wrote: > Hi Jim, Sergey and All, > > Please review the fix that adds support of Retina displays to > JLightweightFrame (which javafx SwingNode is based on). > > webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1 > jira: https://bugs.openjdk.java.net/browse/JDK-8029455 > > (After the fix goes into jdk9 it should be ported to 8u20 as well, > because the functionality is essential for SwingNode.) > > The general idea of the fix is as follows. > > A BufferedImage instance, being created in the context in which the > scale factor is determined and is different from one, is automatically > created with appropriately extended size. The image itself becomes a > scaled image (a "scale" private field is set on it). By the "context" I > mean the circumstances where the BufferedImage is related to a > JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a > GraphicsDevice which determine the scale factor. > > Here are the related changes: > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html > (the resizeBuffer method) > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html > > > The "scale" value of a BufferedImage is used when 1) > BufferedImageGraphicsConfig is created 2) > BufImgSurfaceData.getDefaultScale() is called: > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html > > > The former is used in the GraphicsConfiguration.createCompatibleImage() > calls, and the latter is used in SurfaceManager.getImageScale(Image): > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html > > > A scaled BufferedImage is supported by the SunGraphics2D.drawImage() > primitives. Here's the pattern of how the image may be created and drawn: > > int scale = ; > BufferedImage img = new BufferedImage(width * scale, height * scale, ...); > img.setScale(scale); // an accessor is currently used instead > <...> > g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale > g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a > specified rect > > In the first case, if the BufferedImage is created with an extended > size, the "scale" value of the image matters, it should be drawn as a > HiDPI image. > In the second case, if the BufferedImage is created with an extended > size, the "scale" value of the image doesn't matter (it may not be > evidently set) as the image will anyway be scaled from its physical > bounds into provided logical bounds. This all should (as I suppose) > provide backward compatibility for buffered images that were created in > their logical bounds or without setting the "scale" field. For instance, > the AquaPainter.paintFromSingleCachedImage(...) method creates & draws > an image as follows: > > int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); > int imgW = bounds.width * scale; > int imgH = bounds.height * scale; > BufferedImage img = new BufferedImage(imgW, imgH, ...); > > g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null); > > Here, the img.scale value is not set (I didn't modify this code), and > SunGraphics2D doesn't treat the image as a HiDPI image, however it is > drawn as expected. An alternative way to draw the image would be: > > int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); > int imgW = bounds.width * scale; > int imgH = bounds.height * scale; > BufferedImage img = new BufferedImage(imgW, imgH, ...); > img.setScale(scale); > > g.drawImage(img, bounds.x, bounds.y, ...); > > The result would be the same. > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html > > > The following changes: > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html > > > are defined by this logic. Running Swing via JLightweightFrame (JLF) > makes it "display agnostic". Swing is painted to an off-screen buffer > and it's the host (e.g. SwingNode) that renders the buffer on a > particular device. So, the host should detect the scale of the current > display and set it on JLF. > > However, AWT in order to paint to a volatile image requires > CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates > CGraphicsDevice instances matching all the detected display devices > (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any > platform window behind it, AWT can't match JLF to the exact device it's > currently displayed on. So, on the one hand, AWT doesn't know which > device is current and what is the current scale (the host passes this > value), but from the other hand, AWT has a list of all the > CGraphicsDevice instances. > > I tried to leverage from that fact. The > CPlatformLWView.getGraphicsDevice() method takes the current scale from > the JLF instance, and then tries to match it to an existent device from > the list. In case it can't find a device with the specified scale (which > should not actually happen, unless the host passes an arbitrary scale > value, which is not the case for SwingNode) it takes a default device > and changes its scale forcedly. I'm not sure if I should create a new > dummy device instance instead. The scale factor of the device (which is > then propagated to CGLSurfaceData on its creation) is the only info that > JLF will take from the device to create a scaled volatile image. > > The following changes: > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html > > > were made to map a backing store image to a scale factor. > > The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on > scrolling. The method was not implemented for a graphics with a scale > transform and a BufImgSurfaceData (it threw exceptions). I took that > code, copied it to the BufImgSurfaceData.copyArea(...) and added a > general translation for the coords: > > - > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html > > > It works, but I'm not sure the implementation is eligible (I don't know > the details of the Blit class, at least it warns not to use the same > source and dest). > > The rest of the changes (not covered here) should be clear. > > Testing: > > - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & > embedded into SwingNode [1]). > - Testing both Nimbus and Aqua L&F. > - Setting swing.volatileImageBufferEnabled=false/true for all combinations. > > Currently, I see no regressions and no visual issues comparing a > standalone mode and a SwingSet mode. > > At the end, I suspect there may be some intersection b/w this fix and > the fix which introduced MultiResolutionToolkitImage. Unfortunately, I > didn't yet read that review saga... Please tell me if I should > incorporate anything from that fix. > > Thanks, > Anton. > > [1] There's a SwingSet part of the fix which I'm going to post to the > jfx alias separately. > From anton.tarasov at oracle.com Wed Dec 11 10:40:04 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 11 Dec 2013 14:40:04 +0400 Subject: [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52A77231.1030902@oracle.com> References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com> Message-ID: <52A84104.9040400@oracle.com> Hi Anthony, On 10.12.2013 23:57, Anthony Petrov wrote: > Hi Anton, > > I'm not an expert in HiDPI rendering, so I'll defer to Jim and Sergey to comment on the core > changes. I still have a few comments regarding the fix: > > 1. src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >> 265 contentView.initialize(peer, null); > Are you sure calling view.initialize() from CPW.initializeBase() doesn't introduce any unwanted > side-effects? Interestingly, the contentView field gets re-written and re-initialized in the > CPW.initialize() method after calling the initializeBase(). Seems very strange to me. Oh, this is a miss. I should have put it into CPlatformLWWindow. Thanks for noticing! > > > 2. I'm not sure if adding the scale field to the BI is a good idea. I think that the image > shouldn't be aware of any scale. After all, it's just an image, a bitmap. It has its real > dimensions corresponding to the actual size of the image stored in RAM. Whether this image is > going to be represented as a scaled image is something that a code that uses the image should be > concerned with, not the image itself. There are two options. 1) Follow to your logic, that is to fix every place in AWT/Swing where BufferedImage is created. In which case in every such place we will have to get a current scale factor from the context. 2) Don't touch that code, but solve the task in some generic way, the way I tried to implement, when a buffered image is created with an extended size right in the factory methods. The logic of the first approach is simpler. However, it would require lots of modifications (in the L&F code, and not only there). And it would require to take into account the scale factor every time a new buffered image case is added to the code. Still, this is possible. With the scond approach I don't need to bother about that code, I just create scaled images "on the fly". > I think that the image shouldn't be aware of any scale. The "scale" field put into the BufferedImage class means that an image instance should (or shouldn't) be treated as a HiDPI image by the Graphics.drawImage(). So, this is a kind of a special "scale" case, aimed at supporting Retina technology. Probably it deserves a better name, "hidpiScale" or something. So, it's not that the image has been scaled by the user to be drawn on a lager area, but that the image should (or shouldn't) be scaled just to "look smoothly" on a Retina display. That's what I was thinking about... > > > > 3. src/share/classes/java/awt/peer/FramePeer.java >> 139 default void notifyScaleFactorChanged() {} > > I think this deserves to be declared in WindowPeer so that we could use it w/o additional > modifications in the future if we add support for public notifications about the scale factor > changes. Ok. > > > 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in the JViewport class and > other Swing classes. Thanks for the review! Anton. > > -- > best regards, > Anthony > > On 12/10/2013 06:22 PM, Anton V. Tarasov wrote: >> Hi Jim, Sergey and All, >> >> Please review the fix that adds support of Retina displays to >> JLightweightFrame (which javafx SwingNode is based on). >> >> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1 >> jira: https://bugs.openjdk.java.net/browse/JDK-8029455 >> >> (After the fix goes into jdk9 it should be ported to 8u20 as well, >> because the functionality is essential for SwingNode.) >> >> The general idea of the fix is as follows. >> >> A BufferedImage instance, being created in the context in which the >> scale factor is determined and is different from one, is automatically >> created with appropriately extended size. The image itself becomes a >> scaled image (a "scale" private field is set on it). By the "context" I >> mean the circumstances where the BufferedImage is related to a >> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a >> GraphicsDevice which determine the scale factor. >> >> Here are the related changes: >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html >> >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html >> >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html >> >> (the resizeBuffer method) >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html >> >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html >> >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html >> >> >> >> The "scale" value of a BufferedImage is used when 1) >> BufferedImageGraphicsConfig is created 2) >> BufImgSurfaceData.getDefaultScale() is called: >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html >> >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html >> >> >> >> The former is used in the GraphicsConfiguration.createCompatibleImage() >> calls, and the latter is used in SurfaceManager.getImageScale(Image): >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html >> >> >> >> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() >> primitives. Here's the pattern of how the image may be created and drawn: >> >> int scale = ; >> BufferedImage img = new BufferedImage(width * scale, height * scale, ...); >> img.setScale(scale); // an accessor is currently used instead >> <...> >> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale >> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a >> specified rect >> >> In the first case, if the BufferedImage is created with an extended >> size, the "scale" value of the image matters, it should be drawn as a >> HiDPI image. >> In the second case, if the BufferedImage is created with an extended >> size, the "scale" value of the image doesn't matter (it may not be >> evidently set) as the image will anyway be scaled from its physical >> bounds into provided logical bounds. This all should (as I suppose) >> provide backward compatibility for buffered images that were created in >> their logical bounds or without setting the "scale" field. For instance, >> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws >> an image as follows: >> >> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); >> int imgW = bounds.width * scale; >> int imgH = bounds.height * scale; >> BufferedImage img = new BufferedImage(imgW, imgH, ...); >> >> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null); >> >> Here, the img.scale value is not set (I didn't modify this code), and >> SunGraphics2D doesn't treat the image as a HiDPI image, however it is >> drawn as expected. An alternative way to draw the image would be: >> >> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); >> int imgW = bounds.width * scale; >> int imgH = bounds.height * scale; >> BufferedImage img = new BufferedImage(imgW, imgH, ...); >> img.setScale(scale); >> >> g.drawImage(img, bounds.x, bounds.y, ...); >> >> The result would be the same. >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html >> >> >> >> The following changes: >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html >> >> >> >> are defined by this logic. Running Swing via JLightweightFrame (JLF) >> makes it "display agnostic". Swing is painted to an off-screen buffer >> and it's the host (e.g. SwingNode) that renders the buffer on a >> particular device. So, the host should detect the scale of the current >> display and set it on JLF. >> >> However, AWT in order to paint to a volatile image requires >> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates >> CGraphicsDevice instances matching all the detected display devices >> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any >> platform window behind it, AWT can't match JLF to the exact device it's >> currently displayed on. So, on the one hand, AWT doesn't know which >> device is current and what is the current scale (the host passes this >> value), but from the other hand, AWT has a list of all the >> CGraphicsDevice instances. >> >> I tried to leverage from that fact. The >> CPlatformLWView.getGraphicsDevice() method takes the current scale from >> the JLF instance, and then tries to match it to an existent device from >> the list. In case it can't find a device with the specified scale (which >> should not actually happen, unless the host passes an arbitrary scale >> value, which is not the case for SwingNode) it takes a default device >> and changes its scale forcedly. I'm not sure if I should create a new >> dummy device instance instead. The scale factor of the device (which is >> then propagated to CGLSurfaceData on its creation) is the only info that >> JLF will take from the device to create a scaled volatile image. >> >> The following changes: >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html >> >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html >> >> >> >> were made to map a backing store image to a scale factor. >> >> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on >> scrolling. The method was not implemented for a graphics with a scale >> transform and a BufImgSurfaceData (it threw exceptions). I took that >> code, copied it to the BufImgSurfaceData.copyArea(...) and added a >> general translation for the coords: >> >> - >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html >> >> >> >> It works, but I'm not sure the implementation is eligible (I don't know >> the details of the Blit class, at least it warns not to use the same >> source and dest). >> >> The rest of the changes (not covered here) should be clear. >> >> Testing: >> >> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & >> embedded into SwingNode [1]). >> - Testing both Nimbus and Aqua L&F. >> - Setting swing.volatileImageBufferEnabled=false/true for all combinations. >> >> Currently, I see no regressions and no visual issues comparing a >> standalone mode and a SwingSet mode. >> >> At the end, I suspect there may be some intersection b/w this fix and >> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I >> didn't yet read that review saga... Please tell me if I should >> incorporate anything from that fix. >> >> Thanks, >> Anton. >> >> [1] There's a SwingSet part of the fix which I'm going to post to the >> jfx alias separately. >> From oleg.pekhovskiy at oracle.com Wed Dec 11 11:20:19 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 11 Dec 2013 15:20:19 +0400 Subject: Regression test for 8016551 on Linux/Unix In-Reply-To: References: Message-ID: <52A84A73.60600@oracle.com> Hi Volker, If you familiar with JDK building process, I would propose you to apply the patch from there: http://cr.openjdk.java.net/~bagiras/7033533.2/jdk.patch and check whether it resolves your problem. Thanks, Oleg On 12/09/2013 10:49 PM, Volker Simonis wrote: > Hi Leonid, > > could you please explain, how the regression test you've added for > 8016551 is supposed to work? > > If I run this test standalone or within JTreg with '-othervm' option > on Linux the test displays a frame with the close icon and then it > throws an sun.awt.SunToolkit$OperationTimedOut() exception because of > the call to SunToolkit.realSync(): > > Exception in thread "main" sun.awt.SunToolkit$OperationTimedOut: 10001 > at sun.awt.X11.XToolkit.syncNativeQueue(XToolkit.java:2427) > at sun.awt.SunToolkit.realSync(SunToolkit.java:1501) > at bug8016551.main(bug8016551.java:40) > > Within JTreg, this of course makes the test fail. If running > standalone, the frame will be still displayed until I close the > window. > > If I run the test within JTreg with the '-agentvm' option, it is even > not possible to call setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) on > the created frame, because agent-VMs run with a SecurityManager which > forbids this (also see my mail to > http://mail.openjdk.java.net/pipermail/quality-discuss/2013-December/000175.html): > > ----------System.err:(33/2049)---------- > java.lang.reflect.InvocationTargetException > at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300) > at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275) > at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350) > at bug8016551.main(bug8016551.java:46) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) > at java.lang.Thread.run(Thread.java:744) > Caused by: java.lang.SecurityException: System.exit() forbidden by JT Harness > at com.sun.javatest.JavaTestSecurityManager.checkExit(JavaTestSecurityManager.java:117) > at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:395) > at bug8016551$1.run(bug8016551.java:57) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > at java.awt.EventQueue.access$400(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:697) > at java.awt.EventQueue$3.run(EventQueue.java:691) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > > So I wonder how this test is supposed to work? Who will actually close > the created frame? Or is this supposed to be a manual test? > > Thank you and best regards, > Volker From anthony.petrov at oracle.com Wed Dec 11 19:14:01 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Dec 2013 23:14:01 +0400 Subject: [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52A84104.9040400@oracle.com> References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com> <52A84104.9040400@oracle.com> Message-ID: <52A8B979.5040400@oracle.com> Hi Anton, On 12/11/2013 02:40 PM, Anton V. Tarasov wrote: >> 2. I'm not sure if adding the scale field to the BI is a good idea. I >> think that the image shouldn't be aware of any scale. After all, it's >> just an image, a bitmap. It has its real dimensions corresponding to >> the actual size of the image stored in RAM. Whether this image is >> going to be represented as a scaled image is something that a code >> that uses the image should be concerned with, not the image itself. > > There are two options. 1) Follow to your logic, that is to fix every > place in AWT/Swing where BufferedImage is created. In which case in > every such place we will have to get a current scale factor from the > context. 2) Don't touch that code, but solve the task in some generic > way, the way I tried to implement, when a buffered image is created with > an extended size right in the factory methods. > > The logic of the first approach is simpler. However, it would require > lots of modifications (in the L&F code, and not only there). And it > would require to take into account the scale factor every time a new > buffered image case is added to the code. Still, this is possible. > > With the scond approach I don't need to bother about that code, I just > create scaled images "on the fly". > > > I think that the image shouldn't be aware of any scale. > > The "scale" field put into the BufferedImage class means that an image > instance should (or shouldn't) be treated as a HiDPI image by the > Graphics.drawImage(). So, this is a kind of a special "scale" case, > aimed at supporting Retina technology. Probably it deserves a better > name, "hidpiScale" or something. So, it's not that the image has been > scaled by the user to be drawn on a lager area, but that the image > should (or shouldn't) be scaled just to "look smoothly" on a Retina > display. That's what I was thinking about... Thanks for the clarification. The idea sounds reasonable indeed. I've also read your reply to Jim and I'm now concerned about the fact that scaled images can report larger dimensions than a Graphics created for them would allow one to draw to them. This may be a problem for some apps that perform rendering based on the dimensions of a BI object passed to them. Shouldn't the BI.getWidth/Height() methods always report the logical size of the image, which is equal to the physical one for scale == 1? -- best regards, Anthony > >> >> >> >> 3. src/share/classes/java/awt/peer/FramePeer.java >>> 139 default void notifyScaleFactorChanged() {} >> >> I think this deserves to be declared in WindowPeer so that we could >> use it w/o additional modifications in the future if we add support >> for public notifications about the scale factor changes. > > Ok. > >> >> >> 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in >> the JViewport class and other Swing classes. > > Thanks for the review! > > Anton. > >> >> -- >> best regards, >> Anthony >> >> On 12/10/2013 06:22 PM, Anton V. Tarasov wrote: >>> Hi Jim, Sergey and All, >>> >>> Please review the fix that adds support of Retina displays to >>> JLightweightFrame (which javafx SwingNode is based on). >>> >>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1 >>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455 >>> >>> (After the fix goes into jdk9 it should be ported to 8u20 as well, >>> because the functionality is essential for SwingNode.) >>> >>> The general idea of the fix is as follows. >>> >>> A BufferedImage instance, being created in the context in which the >>> scale factor is determined and is different from one, is automatically >>> created with appropriately extended size. The image itself becomes a >>> scaled image (a "scale" private field is set on it). By the "context" I >>> mean the circumstances where the BufferedImage is related to a >>> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a >>> GraphicsDevice which determine the scale factor. >>> >>> Here are the related changes: >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html >>> >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html >>> >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html >>> >>> (the resizeBuffer method) >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html >>> >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html >>> >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html >>> >>> >>> >>> The "scale" value of a BufferedImage is used when 1) >>> BufferedImageGraphicsConfig is created 2) >>> BufImgSurfaceData.getDefaultScale() is called: >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html >>> >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html >>> >>> >>> >>> The former is used in the GraphicsConfiguration.createCompatibleImage() >>> calls, and the latter is used in SurfaceManager.getImageScale(Image): >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html >>> >>> >>> >>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() >>> primitives. Here's the pattern of how the image may be created and >>> drawn: >>> >>> int scale = ; >>> BufferedImage img = new BufferedImage(width * scale, height * scale, >>> ...); >>> img.setScale(scale); // an accessor is currently used instead >>> <...> >>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale >>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a >>> specified rect >>> >>> In the first case, if the BufferedImage is created with an extended >>> size, the "scale" value of the image matters, it should be drawn as a >>> HiDPI image. >>> In the second case, if the BufferedImage is created with an extended >>> size, the "scale" value of the image doesn't matter (it may not be >>> evidently set) as the image will anyway be scaled from its physical >>> bounds into provided logical bounds. This all should (as I suppose) >>> provide backward compatibility for buffered images that were created in >>> their logical bounds or without setting the "scale" field. For instance, >>> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws >>> an image as follows: >>> >>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); >>> int imgW = bounds.width * scale; >>> int imgH = bounds.height * scale; >>> BufferedImage img = new BufferedImage(imgW, imgH, ...); >>> >>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null); >>> >>> Here, the img.scale value is not set (I didn't modify this code), and >>> SunGraphics2D doesn't treat the image as a HiDPI image, however it is >>> drawn as expected. An alternative way to draw the image would be: >>> >>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); >>> int imgW = bounds.width * scale; >>> int imgH = bounds.height * scale; >>> BufferedImage img = new BufferedImage(imgW, imgH, ...); >>> img.setScale(scale); >>> >>> g.drawImage(img, bounds.x, bounds.y, ...); >>> >>> The result would be the same. >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html >>> >>> >>> >>> The following changes: >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html >>> >>> >>> >>> are defined by this logic. Running Swing via JLightweightFrame (JLF) >>> makes it "display agnostic". Swing is painted to an off-screen buffer >>> and it's the host (e.g. SwingNode) that renders the buffer on a >>> particular device. So, the host should detect the scale of the current >>> display and set it on JLF. >>> >>> However, AWT in order to paint to a volatile image requires >>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates >>> CGraphicsDevice instances matching all the detected display devices >>> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any >>> platform window behind it, AWT can't match JLF to the exact device it's >>> currently displayed on. So, on the one hand, AWT doesn't know which >>> device is current and what is the current scale (the host passes this >>> value), but from the other hand, AWT has a list of all the >>> CGraphicsDevice instances. >>> >>> I tried to leverage from that fact. The >>> CPlatformLWView.getGraphicsDevice() method takes the current scale from >>> the JLF instance, and then tries to match it to an existent device from >>> the list. In case it can't find a device with the specified scale (which >>> should not actually happen, unless the host passes an arbitrary scale >>> value, which is not the case for SwingNode) it takes a default device >>> and changes its scale forcedly. I'm not sure if I should create a new >>> dummy device instance instead. The scale factor of the device (which is >>> then propagated to CGLSurfaceData on its creation) is the only info that >>> JLF will take from the device to create a scaled volatile image. >>> >>> The following changes: >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html >>> >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html >>> >>> >>> >>> were made to map a backing store image to a scale factor. >>> >>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on >>> scrolling. The method was not implemented for a graphics with a scale >>> transform and a BufImgSurfaceData (it threw exceptions). I took that >>> code, copied it to the BufImgSurfaceData.copyArea(...) and added a >>> general translation for the coords: >>> >>> - >>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html >>> >>> >>> >>> It works, but I'm not sure the implementation is eligible (I don't know >>> the details of the Blit class, at least it warns not to use the same >>> source and dest). >>> >>> The rest of the changes (not covered here) should be clear. >>> >>> Testing: >>> >>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & >>> embedded into SwingNode [1]). >>> - Testing both Nimbus and Aqua L&F. >>> - Setting swing.volatileImageBufferEnabled=false/true for all >>> combinations. >>> >>> Currently, I see no regressions and no visual issues comparing a >>> standalone mode and a SwingSet mode. >>> >>> At the end, I suspect there may be some intersection b/w this fix and >>> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I >>> didn't yet read that review saga... Please tell me if I should >>> incorporate anything from that fix. >>> >>> Thanks, >>> Anton. >>> >>> [1] There's a SwingSet part of the fix which I'm going to post to the >>> jfx alias separately. >>> > From james.graham at oracle.com Wed Dec 11 21:30:46 2013 From: james.graham at oracle.com (Jim Graham) Date: Wed, 11 Dec 2013 13:30:46 -0800 Subject: [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52A84104.9040400@oracle.com> References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com> <52A84104.9040400@oracle.com> Message-ID: <52A8D986.20206@oracle.com> On 12/11/13 2:40 AM, Anton V. Tarasov wrote: > On 10.12.2013 23:57, Anthony Petrov wrote: >> I think that the image shouldn't be aware of any scale. > > The "scale" field put into the BufferedImage class means that an image > instance should (or shouldn't) be treated as a HiDPI image by the > Graphics.drawImage(). So, this is a kind of a special "scale" case, > aimed at supporting Retina technology. Probably it deserves a better > name, "hidpiScale" or something. So, it's not that the image has been > scaled by the user to be drawn on a lager area, but that the image > should (or shouldn't) be scaled just to "look smoothly" on a Retina > display. That's what I was thinking about... The problem with this, to me, is that a developer may make the assumption in layout that the image will take "getWidth(null), getHeight(null)" size in the output when rendered with the default "drawImage(img, x, y, obs)" call. You are going to violate that assumption here. Another conflicting issue is that a developer would assume that if an image is "instanceof BufferedImage" then those same dimensions are going to define how much data they can read when they call getRGB(x, y) or get the raster. Something is going to break when trying to use buffered images for auto-scaled output. Perhaps we need a "hidden image type based on buffered image internally" image to use in these cases? Or some sort of "render buffer object" which contains a reference to the image to render into and a concept of the scale it will be rendered to and from rather than baking those concepts directly into BufferedImage...? (Note that we already have this problem in FX as well when we introduced reading from images and HiDPI in the same release, but we want the public object to return the layout sizes - for now we average 4 pixels in the readback to solve the problem, but we do not expose the pixels like BufferedImage and we are going to have to introduce API at some point to allow them to get a pixel readback from a particular scaled version of the image...) If these images are not at all exposed to the developer in any way then I would encourage some solution/mechanism that did not insert itself into BufferedImage. Perhaps we could have SwingBI class that extends BImg and introduces the scale factor at that level, only to be dealt with internally? Or does Swing have a bunch of "new BufferedImage()" calls sprinkled throughout? ...jim From anton.tarasov at oracle.com Thu Dec 12 15:21:04 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 12 Dec 2013 19:21:04 +0400 Subject: [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52A8B979.5040400@oracle.com> References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com> <52A84104.9040400@oracle.com> <52A8B979.5040400@oracle.com> Message-ID: <52A9D460.1090102@oracle.com> [cc'ing to j2d] On 11.12.2013 23:14, Anthony Petrov wrote: > Hi Anton, > > On 12/11/2013 02:40 PM, Anton V. Tarasov wrote: >>> 2. I'm not sure if adding the scale field to the BI is a good idea. I >>> think that the image shouldn't be aware of any scale. After all, it's >>> just an image, a bitmap. It has its real dimensions corresponding to >>> the actual size of the image stored in RAM. Whether this image is >>> going to be represented as a scaled image is something that a code >>> that uses the image should be concerned with, not the image itself. >> >> There are two options. 1) Follow to your logic, that is to fix every >> place in AWT/Swing where BufferedImage is created. In which case in >> every such place we will have to get a current scale factor from the >> context. 2) Don't touch that code, but solve the task in some generic >> way, the way I tried to implement, when a buffered image is created with >> an extended size right in the factory methods. >> >> The logic of the first approach is simpler. However, it would require >> lots of modifications (in the L&F code, and not only there). And it >> would require to take into account the scale factor every time a new >> buffered image case is added to the code. Still, this is possible. >> >> With the scond approach I don't need to bother about that code, I just >> create scaled images "on the fly". >> >> > I think that the image shouldn't be aware of any scale. >> >> The "scale" field put into the BufferedImage class means that an image >> instance should (or shouldn't) be treated as a HiDPI image by the >> Graphics.drawImage(). So, this is a kind of a special "scale" case, >> aimed at supporting Retina technology. Probably it deserves a better >> name, "hidpiScale" or something. So, it's not that the image has been >> scaled by the user to be drawn on a lager area, but that the image >> should (or shouldn't) be scaled just to "look smoothly" on a Retina >> display. That's what I was thinking about... > > Thanks for the clarification. The idea sounds reasonable indeed. > > I've also read your reply to Jim and I'm now concerned about the fact that scaled images can > report larger dimensions than a Graphics created for them would allow one to draw to them. This > may be a problem for some apps that perform rendering based on the dimensions of a BI object > passed to them. > > Shouldn't the BI.getWidth/Height() methods always report the logical size of the image, which is > equal to the physical one for scale == 1? That's probably worth discussing. Let me move this discussion to another thread. Thanks, Anton. > > -- > best regards, > Anthony > >> >>> >>> >>> >>> 3. src/share/classes/java/awt/peer/FramePeer.java >>>> 139 default void notifyScaleFactorChanged() {} >>> >>> I think this deserves to be declared in WindowPeer so that we could >>> use it w/o additional modifications in the future if we add support >>> for public notifications about the scale factor changes. >> >> Ok. >> >>> >>> >>> 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in >>> the JViewport class and other Swing classes. >> >> Thanks for the review! >> >> Anton. >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 12/10/2013 06:22 PM, Anton V. Tarasov wrote: >>>> Hi Jim, Sergey and All, >>>> >>>> Please review the fix that adds support of Retina displays to >>>> JLightweightFrame (which javafx SwingNode is based on). >>>> >>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1 >>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455 >>>> >>>> (After the fix goes into jdk9 it should be ported to 8u20 as well, >>>> because the functionality is essential for SwingNode.) >>>> >>>> The general idea of the fix is as follows. >>>> >>>> A BufferedImage instance, being created in the context in which the >>>> scale factor is determined and is different from one, is automatically >>>> created with appropriately extended size. The image itself becomes a >>>> scaled image (a "scale" private field is set on it). By the "context" I >>>> mean the circumstances where the BufferedImage is related to a >>>> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a >>>> GraphicsDevice which determine the scale factor. >>>> >>>> Here are the related changes: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html >>>> >>>> >>>> (the resizeBuffer method) >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html >>>> >>>> >>>> >>>> >>>> The "scale" value of a BufferedImage is used when 1) >>>> BufferedImageGraphicsConfig is created 2) >>>> BufImgSurfaceData.getDefaultScale() is called: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html >>>> >>>> >>>> >>>> >>>> The former is used in the GraphicsConfiguration.createCompatibleImage() >>>> calls, and the latter is used in SurfaceManager.getImageScale(Image): >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html >>>> >>>> >>>> >>>> >>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() >>>> primitives. Here's the pattern of how the image may be created and >>>> drawn: >>>> >>>> int scale = ; >>>> BufferedImage img = new BufferedImage(width * scale, height * scale, >>>> ...); >>>> img.setScale(scale); // an accessor is currently used instead >>>> <...> >>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale >>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a >>>> specified rect >>>> >>>> In the first case, if the BufferedImage is created with an extended >>>> size, the "scale" value of the image matters, it should be drawn as a >>>> HiDPI image. >>>> In the second case, if the BufferedImage is created with an extended >>>> size, the "scale" value of the image doesn't matter (it may not be >>>> evidently set) as the image will anyway be scaled from its physical >>>> bounds into provided logical bounds. This all should (as I suppose) >>>> provide backward compatibility for buffered images that were created in >>>> their logical bounds or without setting the "scale" field. For instance, >>>> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws >>>> an image as follows: >>>> >>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); >>>> int imgW = bounds.width * scale; >>>> int imgH = bounds.height * scale; >>>> BufferedImage img = new BufferedImage(imgW, imgH, ...); >>>> >>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null); >>>> >>>> Here, the img.scale value is not set (I didn't modify this code), and >>>> SunGraphics2D doesn't treat the image as a HiDPI image, however it is >>>> drawn as expected. An alternative way to draw the image would be: >>>> >>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); >>>> int imgW = bounds.width * scale; >>>> int imgH = bounds.height * scale; >>>> BufferedImage img = new BufferedImage(imgW, imgH, ...); >>>> img.setScale(scale); >>>> >>>> g.drawImage(img, bounds.x, bounds.y, ...); >>>> >>>> The result would be the same. >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html >>>> >>>> >>>> >>>> >>>> The following changes: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html >>>> >>>> >>>> >>>> >>>> are defined by this logic. Running Swing via JLightweightFrame (JLF) >>>> makes it "display agnostic". Swing is painted to an off-screen buffer >>>> and it's the host (e.g. SwingNode) that renders the buffer on a >>>> particular device. So, the host should detect the scale of the current >>>> display and set it on JLF. >>>> >>>> However, AWT in order to paint to a volatile image requires >>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates >>>> CGraphicsDevice instances matching all the detected display devices >>>> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any >>>> platform window behind it, AWT can't match JLF to the exact device it's >>>> currently displayed on. So, on the one hand, AWT doesn't know which >>>> device is current and what is the current scale (the host passes this >>>> value), but from the other hand, AWT has a list of all the >>>> CGraphicsDevice instances. >>>> >>>> I tried to leverage from that fact. The >>>> CPlatformLWView.getGraphicsDevice() method takes the current scale from >>>> the JLF instance, and then tries to match it to an existent device from >>>> the list. In case it can't find a device with the specified scale (which >>>> should not actually happen, unless the host passes an arbitrary scale >>>> value, which is not the case for SwingNode) it takes a default device >>>> and changes its scale forcedly. I'm not sure if I should create a new >>>> dummy device instance instead. The scale factor of the device (which is >>>> then propagated to CGLSurfaceData on its creation) is the only info that >>>> JLF will take from the device to create a scaled volatile image. >>>> >>>> The following changes: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html >>>> >>>> >>>> >>>> >>>> were made to map a backing store image to a scale factor. >>>> >>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on >>>> scrolling. The method was not implemented for a graphics with a scale >>>> transform and a BufImgSurfaceData (it threw exceptions). I took that >>>> code, copied it to the BufImgSurfaceData.copyArea(...) and added a >>>> general translation for the coords: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html >>>> >>>> >>>> >>>> >>>> It works, but I'm not sure the implementation is eligible (I don't know >>>> the details of the Blit class, at least it warns not to use the same >>>> source and dest). >>>> >>>> The rest of the changes (not covered here) should be clear. >>>> >>>> Testing: >>>> >>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & >>>> embedded into SwingNode [1]). >>>> - Testing both Nimbus and Aqua L&F. >>>> - Setting swing.volatileImageBufferEnabled=false/true for all >>>> combinations. >>>> >>>> Currently, I see no regressions and no visual issues comparing a >>>> standalone mode and a SwingSet mode. >>>> >>>> At the end, I suspect there may be some intersection b/w this fix and >>>> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I >>>> didn't yet read that review saga... Please tell me if I should >>>> incorporate anything from that fix. >>>> >>>> Thanks, >>>> Anton. >>>> >>>> [1] There's a SwingSet part of the fix which I'm going to post to the >>>> jfx alias separately. >>>> >> From anton.tarasov at oracle.com Thu Dec 12 15:23:09 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 12 Dec 2013 19:23:09 +0400 Subject: [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52A8B979.5040400@oracle.com> References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com> <52A84104.9040400@oracle.com> <52A8B979.5040400@oracle.com> Message-ID: <52A9D4DD.6010502@oracle.com> [cc'ing to j2d] On 11.12.2013 23:14, Anthony Petrov wrote: > Hi Anton, > > On 12/11/2013 02:40 PM, Anton V. Tarasov wrote: >>> 2. I'm not sure if adding the scale field to the BI is a good idea. I >>> think that the image shouldn't be aware of any scale. After all, it's >>> just an image, a bitmap. It has its real dimensions corresponding to >>> the actual size of the image stored in RAM. Whether this image is >>> going to be represented as a scaled image is something that a code >>> that uses the image should be concerned with, not the image itself. >> >> There are two options. 1) Follow to your logic, that is to fix every >> place in AWT/Swing where BufferedImage is created. In which case in >> every such place we will have to get a current scale factor from the >> context. 2) Don't touch that code, but solve the task in some generic >> way, the way I tried to implement, when a buffered image is created with >> an extended size right in the factory methods. >> >> The logic of the first approach is simpler. However, it would require >> lots of modifications (in the L&F code, and not only there). And it >> would require to take into account the scale factor every time a new >> buffered image case is added to the code. Still, this is possible. >> >> With the scond approach I don't need to bother about that code, I just >> create scaled images "on the fly". >> >> > I think that the image shouldn't be aware of any scale. >> >> The "scale" field put into the BufferedImage class means that an image >> instance should (or shouldn't) be treated as a HiDPI image by the >> Graphics.drawImage(). So, this is a kind of a special "scale" case, >> aimed at supporting Retina technology. Probably it deserves a better >> name, "hidpiScale" or something. So, it's not that the image has been >> scaled by the user to be drawn on a lager area, but that the image >> should (or shouldn't) be scaled just to "look smoothly" on a Retina >> display. That's what I was thinking about... > > Thanks for the clarification. The idea sounds reasonable indeed. > > I've also read your reply to Jim and I'm now concerned about the fact that scaled images can > report larger dimensions than a Graphics created for them would allow one to draw to them. This > may be a problem for some apps that perform rendering based on the dimensions of a BI object > passed to them. > > Shouldn't the BI.getWidth/Height() methods always report the logical size of the image, which is > equal to the physical one for scale == 1? That's probably worth discussing. Let me move this discussion to another thread. Thanks, Anton. > > -- > best regards, > Anthony > >> >>> >>> >>> >>> 3. src/share/classes/java/awt/peer/FramePeer.java >>>> 139 default void notifyScaleFactorChanged() {} >>> >>> I think this deserves to be declared in WindowPeer so that we could >>> use it w/o additional modifications in the future if we add support >>> for public notifications about the scale factor changes. >> >> Ok. >> >>> >>> >>> 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in >>> the JViewport class and other Swing classes. >> >> Thanks for the review! >> >> Anton. >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 12/10/2013 06:22 PM, Anton V. Tarasov wrote: >>>> Hi Jim, Sergey and All, >>>> >>>> Please review the fix that adds support of Retina displays to >>>> JLightweightFrame (which javafx SwingNode is based on). >>>> >>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1 >>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455 >>>> >>>> (After the fix goes into jdk9 it should be ported to 8u20 as well, >>>> because the functionality is essential for SwingNode.) >>>> >>>> The general idea of the fix is as follows. >>>> >>>> A BufferedImage instance, being created in the context in which the >>>> scale factor is determined and is different from one, is automatically >>>> created with appropriately extended size. The image itself becomes a >>>> scaled image (a "scale" private field is set on it). By the "context" I >>>> mean the circumstances where the BufferedImage is related to a >>>> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a >>>> GraphicsDevice which determine the scale factor. >>>> >>>> Here are the related changes: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html >>>> >>>> >>>> (the resizeBuffer method) >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html >>>> >>>> >>>> >>>> >>>> The "scale" value of a BufferedImage is used when 1) >>>> BufferedImageGraphicsConfig is created 2) >>>> BufImgSurfaceData.getDefaultScale() is called: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html >>>> >>>> >>>> >>>> >>>> The former is used in the GraphicsConfiguration.createCompatibleImage() >>>> calls, and the latter is used in SurfaceManager.getImageScale(Image): >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html >>>> >>>> >>>> >>>> >>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() >>>> primitives. Here's the pattern of how the image may be created and >>>> drawn: >>>> >>>> int scale = ; >>>> BufferedImage img = new BufferedImage(width * scale, height * scale, >>>> ...); >>>> img.setScale(scale); // an accessor is currently used instead >>>> <...> >>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale >>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a >>>> specified rect >>>> >>>> In the first case, if the BufferedImage is created with an extended >>>> size, the "scale" value of the image matters, it should be drawn as a >>>> HiDPI image. >>>> In the second case, if the BufferedImage is created with an extended >>>> size, the "scale" value of the image doesn't matter (it may not be >>>> evidently set) as the image will anyway be scaled from its physical >>>> bounds into provided logical bounds. This all should (as I suppose) >>>> provide backward compatibility for buffered images that were created in >>>> their logical bounds or without setting the "scale" field. For instance, >>>> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws >>>> an image as follows: >>>> >>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); >>>> int imgW = bounds.width * scale; >>>> int imgH = bounds.height * scale; >>>> BufferedImage img = new BufferedImage(imgW, imgH, ...); >>>> >>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null); >>>> >>>> Here, the img.scale value is not set (I didn't modify this code), and >>>> SunGraphics2D doesn't treat the image as a HiDPI image, however it is >>>> drawn as expected. An alternative way to draw the image would be: >>>> >>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale(); >>>> int imgW = bounds.width * scale; >>>> int imgH = bounds.height * scale; >>>> BufferedImage img = new BufferedImage(imgW, imgH, ...); >>>> img.setScale(scale); >>>> >>>> g.drawImage(img, bounds.x, bounds.y, ...); >>>> >>>> The result would be the same. >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html >>>> >>>> >>>> >>>> >>>> The following changes: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html >>>> >>>> >>>> >>>> >>>> are defined by this logic. Running Swing via JLightweightFrame (JLF) >>>> makes it "display agnostic". Swing is painted to an off-screen buffer >>>> and it's the host (e.g. SwingNode) that renders the buffer on a >>>> particular device. So, the host should detect the scale of the current >>>> display and set it on JLF. >>>> >>>> However, AWT in order to paint to a volatile image requires >>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates >>>> CGraphicsDevice instances matching all the detected display devices >>>> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any >>>> platform window behind it, AWT can't match JLF to the exact device it's >>>> currently displayed on. So, on the one hand, AWT doesn't know which >>>> device is current and what is the current scale (the host passes this >>>> value), but from the other hand, AWT has a list of all the >>>> CGraphicsDevice instances. >>>> >>>> I tried to leverage from that fact. The >>>> CPlatformLWView.getGraphicsDevice() method takes the current scale from >>>> the JLF instance, and then tries to match it to an existent device from >>>> the list. In case it can't find a device with the specified scale (which >>>> should not actually happen, unless the host passes an arbitrary scale >>>> value, which is not the case for SwingNode) it takes a default device >>>> and changes its scale forcedly. I'm not sure if I should create a new >>>> dummy device instance instead. The scale factor of the device (which is >>>> then propagated to CGLSurfaceData on its creation) is the only info that >>>> JLF will take from the device to create a scaled volatile image. >>>> >>>> The following changes: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html >>>> >>>> >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html >>>> >>>> >>>> >>>> >>>> were made to map a backing store image to a scale factor. >>>> >>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on >>>> scrolling. The method was not implemented for a graphics with a scale >>>> transform and a BufImgSurfaceData (it threw exceptions). I took that >>>> code, copied it to the BufImgSurfaceData.copyArea(...) and added a >>>> general translation for the coords: >>>> >>>> - >>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html >>>> >>>> >>>> >>>> >>>> It works, but I'm not sure the implementation is eligible (I don't know >>>> the details of the Blit class, at least it warns not to use the same >>>> source and dest). >>>> >>>> The rest of the changes (not covered here) should be clear. >>>> >>>> Testing: >>>> >>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & >>>> embedded into SwingNode [1]). >>>> - Testing both Nimbus and Aqua L&F. >>>> - Setting swing.volatileImageBufferEnabled=false/true for all >>>> combinations. >>>> >>>> Currently, I see no regressions and no visual issues comparing a >>>> standalone mode and a SwingSet mode. >>>> >>>> At the end, I suspect there may be some intersection b/w this fix and >>>> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I >>>> didn't yet read that review saga... Please tell me if I should >>>> incorporate anything from that fix. >>>> >>>> Thanks, >>>> Anton. >>>> >>>> [1] There's a SwingSet part of the fix which I'm going to post to the >>>> jfx alias separately. >>>> >> From anton.tarasov at oracle.com Thu Dec 12 15:50:30 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 12 Dec 2013 19:50:30 +0400 Subject: [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52A8D986.20206@oracle.com> References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com> <52A84104.9040400@oracle.com> <52A8D986.20206@oracle.com> Message-ID: <52A9DB46.6090304@oracle.com> [cc'ing to j2d] On 12.12.2013 1:30, Jim Graham wrote: > > > On 12/11/13 2:40 AM, Anton V. Tarasov wrote: >> On 10.12.2013 23:57, Anthony Petrov wrote: >>> I think that the image shouldn't be aware of any scale. >> >> The "scale" field put into the BufferedImage class means that an image >> instance should (or shouldn't) be treated as a HiDPI image by the >> Graphics.drawImage(). So, this is a kind of a special "scale" case, >> aimed at supporting Retina technology. Probably it deserves a better >> name, "hidpiScale" or something. So, it's not that the image has been >> scaled by the user to be drawn on a lager area, but that the image >> should (or shouldn't) be scaled just to "look smoothly" on a Retina >> display. That's what I was thinking about... > > The problem with this, to me, is that a developer may make the assumption in layout that the image > will take "getWidth(null), getHeight(null)" size in the output when rendered with the default > "drawImage(img, x, y, obs)" call. You are going to violate that assumption here. > > Another conflicting issue is that a developer would assume that if an image is "instanceof > BufferedImage" then those same dimensions are going to define how much data they can read when > they call getRGB(x, y) or get the raster. > > Something is going to break when trying to use buffered images for auto-scaled output. Ok, there's another option, it's to return a layout size from getWidth/getHeight (as Anthony suggested). But this doesn't solve the problem with the raster and the backing array which will be of scaled length... > > Perhaps we need a "hidden image type based on buffered image internally" image to use in these > cases? Or some sort of "render buffer object" which contains a reference to the image to render > into and a concept of the scale it will be rendered to and from rather than baking those concepts > directly into BufferedImage...? > > (Note that we already have this problem in FX as well when we introduced reading from images and > HiDPI in the same release, but we want the public object to return the layout sizes - for now we > average 4 pixels in the readback to solve the problem, but we do not expose the pixels like > BufferedImage and we are going to have to introduce API at some point to allow them to get a pixel > readback from a particular scaled version of the image...) > > If these images are not at all exposed to the developer in any way then I would encourage some > solution/mechanism that did not insert itself into BufferedImage. Perhaps we could have SwingBI > class that extends BImg and introduces the scale factor at that level, only to be dealt with > internally? Or does Swing have a bunch of "new BufferedImage()" calls sprinkled throughout? Swing indirectly creates a BufferedImage via the factory methods: createCompatibleVolatileImage/createCompatibleImage/createImage. The question is if we can't export a scaled version of a BufferedImage, then what options do we have? What comes to my mind is this: 1) In every place such a method is called, call for a (internal private) "scaled version" of the method. 2) Somehow detect when the method is called by Swing and return a scaled BufferedImage or otherwise return a plain image. Not sure if a good solution exists. Thanks, Anton. > > ...jim From sergey.malenkov at oracle.com Tue Dec 17 13:58:18 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Tue, 17 Dec 2013 17:58:18 +0400 Subject: [8] Review request for 8030118: Document listeners fired outside document lock Message-ID: <52B0587A.8030604@oracle.com> Hello, Could you please review the following fix: fix:http://cr.openjdk.java.net/~malenkov/8030118.9.0/ bug:https://bugs.openjdk.java.net/browse/JDK-8030118 We must revert the 7146146 fix that contradicts the specification: "The code path for any DocumentListener implementation and any UndoListener implementation must be threadsafe, and not access the component lock if trying to be safe from deadlocks". Thanks, SAM From Sergey.Bylokhov at oracle.com Tue Dec 17 14:36:46 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Dec 2013 18:36:46 +0400 Subject: [8] Review request for 8030118: Document listeners fired outside document lock In-Reply-To: <52B0587A.8030604@oracle.com> References: <52B0587A.8030604@oracle.com> Message-ID: <52B0617E.7060604@oracle.com> Hi, Sergey. The fix looks good. Can you submit additional CR for initial deadlock. It would be good to look at it. On 17.12.2013 17:58, sergey malenkov wrote: > Hello, > > Could you please review the following fix: > fix:http://cr.openjdk.java.net/~malenkov/8030118.9.0/ > bug:https://bugs.openjdk.java.net/browse/JDK-8030118 > > We must revert the 7146146 fix that contradicts the specification: > "The code path for any DocumentListener implementation and any > UndoListener implementation must be threadsafe, and not access the > component lock if trying to be safe from deadlocks". > > Thanks, > SAM > -- Best regards, Sergey. From artem.ananiev at oracle.com Wed Dec 18 09:53:17 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 18 Dec 2013 13:53:17 +0400 Subject: [8] Review request for 8030118: Document listeners fired outside document lock In-Reply-To: <52B0617E.7060604@oracle.com> References: <52B0587A.8030604@oracle.com> <52B0617E.7060604@oracle.com> Message-ID: <52B1708D.2090800@oracle.com> The fix looks fine, but Sergey B. is right, a new bug must be filed to fix the initial deadlock (7146146). Thanks, Artem On 12/17/2013 6:36 PM, Sergey Bylokhov wrote: > Hi, Sergey. > The fix looks good. > Can you submit additional CR for initial deadlock. It would be good to > look at it. > > On 17.12.2013 17:58, sergey malenkov wrote: >> Hello, >> >> Could you please review the following fix: >> fix:http://cr.openjdk.java.net/~malenkov/8030118.9.0/ >> bug:https://bugs.openjdk.java.net/browse/JDK-8030118 >> >> We must revert the 7146146 fix that contradicts the specification: >> "The code path for any DocumentListener implementation and any >> UndoListener implementation must be threadsafe, and not access the >> component lock if trying to be safe from deadlocks". >> >> Thanks, >> SAM >> > > From Sergey.Bylokhov at oracle.com Mon Dec 23 14:11:21 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Dec 2013 18:11:21 +0400 Subject: [9] Review Request: 8009919 [macosx] NPE in AquaSingleImagePainter.paint() Message-ID: <52B84489.4080207@oracle.com> Hello. Please review the fix for jdk 9. Initial bug was accidentally fixed as a part of JDK-8004866. This is the test for this problem. The test draws jbutton to the graphics of buffered image without initial clip. Bug: https://bugs.openjdk.java.net/browse/JDK-8009919 Webrev can be found at: http://cr.openjdk.java.net/~serb/8009919/webrev.00 -- Best regards, Sergey. From petr.pchelko at oracle.com Mon Dec 23 14:19:18 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 23 Dec 2013 18:19:18 +0400 Subject: [9] Review Request: 8009919 [macosx] NPE in AquaSingleImagePainter.paint() In-Reply-To: <52B84489.4080207@oracle.com> References: <52B84489.4080207@oracle.com> Message-ID: <4FC18C53-72C1-48BD-8BCD-06268E765352@oracle.com> Hello, Sergey. The fix looks good. With best regards. Petr. On 23.12.2013, at 18:11, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > Initial bug was accidentally fixed as a part of JDK-8004866. This is the test for this problem. > The test draws jbutton to the graphics of buffered image without initial clip. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8009919 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8009919/webrev.00 > > -- > Best regards, Sergey. > From alexander.zvegintsev at oracle.com Mon Dec 23 14:31:26 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 23 Dec 2013 18:31:26 +0400 Subject: [9] Review Request: 8009919 [macosx] NPE in AquaSingleImagePainter.paint() In-Reply-To: <4FC18C53-72C1-48BD-8BCD-06268E765352@oracle.com> References: <52B84489.4080207@oracle.com> <4FC18C53-72C1-48BD-8BCD-06268E765352@oracle.com> Message-ID: <52B8493E.9090808@oracle.com> Hi Sergey, The fix looks good to me as well. Thanks, Alexander. On 12/23/2013 06:19 PM, Petr Pchelko wrote: > Hello, Sergey. > > The fix looks good. > > With best regards. Petr. > > On 23.12.2013, at 18:11, Sergey Bylokhov wrote: > >> Hello. >> Please review the fix for jdk 9. >> Initial bug was accidentally fixed as a part of JDK-8004866. This is the test for this problem. >> The test draws jbutton to the graphics of buffered image without initial clip. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8009919 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/8009919/webrev.00 >> >> -- >> Best regards, Sergey. >> From joe.darcy at oracle.com Tue Dec 31 08:51:52 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 31 Dec 2013 00:51:52 -0800 Subject: JDK 9 RFR of JDK-8031082 Fix non-missing doclint problems in client libraries Message-ID: <52C285A8.9060207@oracle.com> Hello, Please review my fix for JDK-8031082 Fix non-missing doclint problems in client libraries The fix resolves nearly all of the outstanding doclint issues in the client libraries, others than the missing javadoc tags. The affected files are src/share/classes/java/awt/Graphics2D.java src/share/classes/java/awt/MediaTracker.java src/share/classes/java/awt/font/TextAttribute.java src/share/classes/java/awt/peer/ComponentPeer.java src/share/classes/java/awt/peer/DialogPeer.java src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java src/share/classes/java/awt/peer/MouseInfoPeer.java src/share/classes/java/awt/peer/PanelPeer.java src/share/classes/java/awt/peer/TextAreaPeer.java src/share/classes/java/awt/peer/WindowPeer.java src/share/classes/java/awt/print/Paper.java src/share/classes/java/awt/print/Printable.java src/share/classes/java/beans/XMLEncoder.java src/share/classes/javax/accessibility/AccessibleContext.java src/share/classes/javax/imageio/ImageWriter.java src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java src/share/classes/javax/imageio/stream/ImageInputStream.java src/share/classes/javax/imageio/stream/ImageOutputStream.java src/share/classes/javax/print/Doc.java src/share/classes/javax/print/DocFlavor.java src/share/classes/javax/print/MultiDoc.java src/share/classes/javax/print/MultiDocPrintJob.java src/share/classes/javax/print/ServiceUI.java src/share/classes/javax/print/StreamPrintServiceFactory.java src/share/classes/javax/print/attribute/AttributeSet.java src/share/classes/javax/print/attribute/standard/Chromaticity.java src/share/classes/javax/print/attribute/standard/Copies.java src/share/classes/javax/print/attribute/standard/Fidelity.java src/share/classes/javax/print/attribute/standard/Finishings.java src/share/classes/javax/print/attribute/standard/JobKOctets.java src/share/classes/javax/print/attribute/standard/JobState.java src/share/classes/javax/print/attribute/standard/MediaName.java src/share/classes/javax/print/attribute/standard/MediaSize.java src/share/classes/javax/print/attribute/standard/MediaSizeName.java src/share/classes/javax/print/attribute/standard/MediaTray.java src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java src/share/classes/javax/print/attribute/standard/NumberUp.java src/share/classes/javax/print/attribute/standard/PageRanges.java src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java src/share/classes/javax/print/attribute/standard/PrinterResolution.java src/share/classes/javax/print/attribute/standard/SheetCollate.java src/share/classes/javax/print/attribute/standard/Sides.java src/share/classes/javax/sound/sampled/AudioInputStream.java src/share/classes/javax/sound/sampled/AudioPermission.java src/share/classes/javax/sound/sampled/ReverbType.java src/share/classes/javax/swing/DefaultComboBoxModel.java src/share/classes/javax/swing/JComboBox.java src/share/classes/javax/swing/JEditorPane.java src/share/classes/javax/swing/JLabel.java src/share/classes/javax/swing/JLayeredPane.java src/share/classes/javax/swing/JOptionPane.java src/share/classes/javax/swing/JTextArea.java src/share/classes/javax/swing/JTextPane.java src/share/classes/javax/swing/plaf/TextUI.java src/share/classes/javax/swing/plaf/basic/BasicTextUI.java src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java src/share/classes/javax/swing/text/CompositeView.java src/share/classes/javax/swing/text/DefaultEditorKit.java src/share/classes/javax/swing/text/Document.java src/share/classes/javax/swing/text/GlyphView.java src/share/classes/javax/swing/text/JTextComponent.java src/share/classes/javax/swing/text/NavigationFilter.java src/share/classes/javax/swing/text/html/HTMLDocument.java src/share/classes/javax/swing/text/html/StyleSheet.java and the full webrev is hosted at http://cr.openjdk.java.net/~darcy/8031082.0/ Thanks, -Joe