date:20160204

Re: javapackager

2016-02-04 Thread Chris Bensen


> On Feb 3, 2016, at 1:08 PM, Scott Palmer  wrote:
> 
> 
>> On Feb 3, 2016, at 11:40 AM, Chris Bensen  wrote:
>> 
>> On Feb 2, 2016, at 7:27 PM, Scott Palmer  wrote:
>>> 
>>> Note that this is a RPM-based system, apt-get is not available, yum is.
>>> 
>>> yum install libX11
>> 
>> What is the Linux system you are running?
> 
> It is a version of CentOS.  (Created within my company with minor tweaks for 
> branding purposes.)

When submitting a bug, make sure the test case works on Oracle Linux or Ubuntu 
since those are the only “supported” version of Linux.

> 
> 
>>> 
>>> It seems to be that javapackager has made a mistake and is claiming to 
>>> depend on the 32-bit packages even though it really requires the 64-bit 
>>> packages.
>> 
>> That’s what it’s sounding like to me. Looking at the code for the RPM 
>> bundler there isn’t anything I can find offhand that would suggest this. 
>> Bundling with 32/64-bit is triggered off the JDK used. Note that you have to 
>> bundle the same bitness JRE as the JDK. It should fail if it isn’t but that 
>> isn’t the case yet and that isn’t your problem. It appears the RPM generated 
>> is 32-bit. Unless you are bundling a 32-bit JRE and the RPM bundler keys off 
>> the native libraries used. Can you check the launcher executable? I think 
>> it’d be:
>> 
>> $ file myserver-1.0-1.x86_64/app/myserver
> 
> I had to extract the launcher from the .rpm.  There is no version of it that 
> is sitting around in the output folder.
> 
> myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> linked (uses shared libs), for GNU/Linux 2.6.15, 
> BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped
> 
> 
> So the 64-bit launcher is bundled.
> 
> 
>> 
>> Can you file a minimum test case along with the Linux system used so we can 
>> prioritize with other bugs and find a solution?
> 
> I’ll try to put something together.  I’m still eager to find a workaround 
> that I can implement with 8u72.
> 
> 
> Scott
> 
> 
>> 
>> Chris
>> 
>> 
>>> Scott 
>>> 
>>> 
 On Feb 2, 2016, at 7:03 PM, Chris Bensen  wrote:
 
 This list or the Deployment blog 
 (https://blogs.oracle.com/talkingjavadeployment/) are the best places to 
 get help with the javapackager.
 
 Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
 appended to the name. If it’s 32-bit you could try running:
 
 sudo apt-get install libx11-6:i386
 
 Chris
 
 
> On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
> 
> What's the best place to go to get help with using the javapackager ?
> 
> I've read the docs, but things aren't working smoothly and it would be
> helpful if there were some known working examples to base things on.  I'm
> not finding any examples that use the -daemon or -BserviceHint=true
> options, for example.
> 
> I attempted to make a .rpm that installs a service/daemon but when I try 
> to
> install it, it fails claiming the following dependencies cannot be met:
> 
>libX11.so.6 is needed by myserver-1.0-1.x86_64
>libXext.so.6 is needed by myserver-1.0-1.x86_64
>libXi.so.6 is needed by myserver-1.0-1.x86_64
>libXrender.so.1 is needed by myserver-1.0-1.x86_64
>libXtst.so.6 is needed by myserver-1.0-1.x86_64
>libasound.so.2 is needed by myserver-1.0-1.x86_64
> 
> Considering the app already runs fine on this same system, I'm a bit
> confused that it is complaining of missing dependencies.
> 
> Scott
>

Re: Canvas Clip performance

2016-02-04 Thread Philip Race




On 2/4/16, 2:59 PM, Elric Morgenstern wrote:

I see. Interesting. Isn't there a switch to toggle it on JDK8?


There is no switch that can enable it if it is disabled by 'default'.


Assuming you are talking about JavaFX, right? Because you were referring to
Java2D in your reply.


No I am talking about 2D. What I meant was that maybe the performance issue
is inherent in the card and the only reason it looks OK with Java2D on 
Intel is
that we aren't using anything much at all of the Intel chip and are 
doing the work

on the cpu instead.

-phil.



On Thu, Feb 4, 2016 at 11:52 PM, Philip Race  wrote:


Java 2D does not (generally) enable D3D on Intel.
We tried for JDK 8 but there were problems and it was disabled again in
8u40 I think.
JDK 9 EA builds (currently) still have it enabled to help get some testing
so
if you are running an 8ux release you might want to switch to 9 to get a
fairer comparison.

-phil.



On 2/4/16, 2:49 PM, Elric Morgenstern wrote:


Hi guys,

I've noticed that clipping performance (Canvas GraphicsContext) is
extremely bad on an Intel HD graphics chip. One rectangular clip is fine,
anything beyond that, or a spherical clip shape, will bring the framerate
to its knees.

I notice no performance difference on my GeForce system, but on the
integrated chip my application is basically insufferable.

The same thing performed with Java2D experiences no performance issues on
neither system.

Any ideas?

Re: Canvas Clip performance

2016-02-04 Thread Elric Morgenstern

I see. Interesting. Isn't there a switch to toggle it on JDK8?

Assuming you are talking about JavaFX, right? Because you were referring to
Java2D in your reply.

On Thu, Feb 4, 2016 at 11:52 PM, Philip Race  wrote:

> Java 2D does not (generally) enable D3D on Intel.
> We tried for JDK 8 but there were problems and it was disabled again in
> 8u40 I think.
> JDK 9 EA builds (currently) still have it enabled to help get some testing
> so
> if you are running an 8ux release you might want to switch to 9 to get a
> fairer comparison.
>
> -phil.
>
>
>
> On 2/4/16, 2:49 PM, Elric Morgenstern wrote:
>
>> Hi guys,
>>
>> I've noticed that clipping performance (Canvas GraphicsContext) is
>> extremely bad on an Intel HD graphics chip. One rectangular clip is fine,
>> anything beyond that, or a spherical clip shape, will bring the framerate
>> to its knees.
>>
>> I notice no performance difference on my GeForce system, but on the
>> integrated chip my application is basically insufferable.
>>
>> The same thing performed with Java2D experiences no performance issues on
>> neither system.
>>
>> Any ideas?
>>
>

Re: Canvas Clip performance

2016-02-04 Thread Philip Race


Java 2D does not (generally) enable D3D on Intel.
We tried for JDK 8 but there were problems and it was disabled again in 
8u40 I think.
JDK 9 EA builds (currently) still have it enabled to help get some 
testing so
if you are running an 8ux release you might want to switch to 9 to get a 
fairer comparison.


-phil.


On 2/4/16, 2:49 PM, Elric Morgenstern wrote:

Hi guys,

I've noticed that clipping performance (Canvas GraphicsContext) is
extremely bad on an Intel HD graphics chip. One rectangular clip is fine,
anything beyond that, or a spherical clip shape, will bring the framerate
to its knees.

I notice no performance difference on my GeForce system, but on the
integrated chip my application is basically insufferable.

The same thing performed with Java2D experiences no performance issues on
neither system.

Any ideas?

Canvas Clip performance

2016-02-04 Thread Elric Morgenstern

Hi guys,

I've noticed that clipping performance (Canvas GraphicsContext) is
extremely bad on an Intel HD graphics chip. One rectangular clip is fine,
anything beyond that, or a spherical clip shape, will bring the framerate
to its knees.

I notice no performance difference on my GeForce system, but on the
integrated chip my application is basically insufferable.

The same thing performed with Java2D experiences no performance issues on
neither system.

Any ideas?

Re: javapackager

2016-02-04 Thread Chris Bensen

There weren’t any noticeable changes for Linux. Besides maybe this one, which 
if you could file a bug with steps to reproduce that’d be great.

Chris


> On Feb 4, 2016, at 7:12 AM, Scott Palmer  wrote:
> 
> I noticed that the JDK on my Linux VM was 8u40,  I updated to 8u72 and then 
> got the following:
> 
> Bundler RPM Bundle skipped because of a configuration problem: Specified 
> license file is missing.  
> Advice to fix: Make sure that "EULA.rtf" references a file in the app 
> resources, and that it is relative file reference.
> 
> I wasn't able to do anything to convince it that the license file was there. 
> I just omitted it for now.
> 
> Updating to 8u72 did not solve my .rpm dependency issues.
> 
> Scott
> 
> On Wed, Feb 3, 2016 at 4:08 PM, Scott Palmer  > wrote:
> 
> > On Feb 3, 2016, at 11:40 AM, Chris Bensen  > > wrote:
> >
> > On Feb 2, 2016, at 7:27 PM, Scott Palmer  > > wrote:
> >>
> >> Note that this is a RPM-based system, apt-get is not available, yum is.
> >>
> >> yum install libX11
> >
> > What is the Linux system you are running?
> 
> It is a version of CentOS.  (Created within my company with minor tweaks for 
> branding purposes.)
> 
> 
> >>
> >> It seems to be that javapackager has made a mistake and is claiming to 
> >> depend on the 32-bit packages even though it really requires the 64-bit 
> >> packages.
> >
> > That’s what it’s sounding like to me. Looking at the code for the RPM 
> > bundler there isn’t anything I can find offhand that would suggest this. 
> > Bundling with 32/64-bit is triggered off the JDK used. Note that you have 
> > to bundle the same bitness JRE as the JDK. It should fail if it isn’t but 
> > that isn’t the case yet and that isn’t your problem. It appears the RPM 
> > generated is 32-bit. Unless you are bundling a 32-bit JRE and the RPM 
> > bundler keys off the native libraries used. Can you check the launcher 
> > executable? I think it’d be:
> >
> > $ file myserver-1.0-1.x86_64/app/myserver
> 
> I had to extract the launcher from the .rpm.  There is no version of it that 
> is sitting around in the output folder.
> 
> myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> linked (uses shared libs), for GNU/Linux 2.6.15, 
> BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped
> 
> 
> So the 64-bit launcher is bundled.
> 
> 
> >
> > Can you file a minimum test case along with the Linux system used so we can 
> > prioritize with other bugs and find a solution?
> 
> I’ll try to put something together.  I’m still eager to find a workaround 
> that I can implement with 8u72.
> 
> 
> Scott
> 
> 
> >
> > Chris
> >
> >
> >> Scott
> >>
> >>
> >>> On Feb 2, 2016, at 7:03 PM, Chris Bensen  >>> > wrote:
> >>>
> >>> This list or the Deployment blog 
> >>> (https://blogs.oracle.com/talkingjavadeployment/ 
> >>> ) are the best places to 
> >>> get help with the javapackager.
> >>>
> >>> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
> >>> appended to the name. If it’s 32-bit you could try running:
> >>>
> >>> sudo apt-get install libx11-6:i386
> >>>
> >>> Chris
> >>>
> >>>
>  On Feb 2, 2016, at 1:49 PM, Scott Palmer   > wrote:
> 
>  What's the best place to go to get help with using the javapackager ?
> 
>  I've read the docs, but things aren't working smoothly and it would be
>  helpful if there were some known working examples to base things on.  I'm
>  not finding any examples that use the -daemon or -BserviceHint=true
>  options, for example.
> 
>  I attempted to make a .rpm that installs a service/daemon but when I try 
>  to
>  install it, it fails claiming the following dependencies cannot be met:
> 
>  libX11.so.6 is needed by myserver-1.0-1.x86_64
>  libXext.so.6 is needed by myserver-1.0-1.x86_64
>  libXi.so.6 is needed by myserver-1.0-1.x86_64
>  libXrender.so.1 is needed by myserver-1.0-1.x86_64
>  libXtst.so.6 is needed by myserver-1.0-1.x86_64
>  libasound.so.2 is needed by myserver-1.0-1.x86_64
> 
>  Considering the app already runs fine on this same system, I'm a bit
>  confused that it is complaining of missing dependencies.
> 
>  Scott
> 
>

[9] Request for review: 8143158 [Text, TextFlow] Make public API from internal "impl" APIs

2016-02-04 Thread Leif Samuelsson


Hi Kevin,

Please review the implementation of the new API.

  https://bugs.openjdk.java.net/browse/JDK-8143158
  http://cr.openjdk.java.net/~leifs/8143158/webrev.01/

Thanks,
Leif

Re: javapackager

2016-02-04 Thread Scott Palmer

I noticed that the JDK on my Linux VM was 8u40,  I updated to 8u72 and then
got the following:

Bundler RPM Bundle skipped because of a configuration problem: Specified
license file is missing.
Advice to fix: Make sure that "EULA.rtf" references a file in the app
resources, and that it is relative file reference.

I wasn't able to do anything to convince it that the license file was
there. I just omitted it for now.

Updating to 8u72 did not solve my .rpm dependency issues.

Scott

On Wed, Feb 3, 2016 at 4:08 PM, Scott Palmer  wrote:

>
> > On Feb 3, 2016, at 11:40 AM, Chris Bensen 
> wrote:
> >
> > On Feb 2, 2016, at 7:27 PM, Scott Palmer  wrote:
> >>
> >> Note that this is a RPM-based system, apt-get is not available, yum is.
> >>
> >> yum install libX11
> >
> > What is the Linux system you are running?
>
> It is a version of CentOS.  (Created within my company with minor tweaks
> for branding purposes.)
>
>
> >>
> >> It seems to be that javapackager has made a mistake and is claiming to
> depend on the 32-bit packages even though it really requires the 64-bit
> packages.
> >
> > That’s what it’s sounding like to me. Looking at the code for the RPM
> bundler there isn’t anything I can find offhand that would suggest this.
> Bundling with 32/64-bit is triggered off the JDK used. Note that you have
> to bundle the same bitness JRE as the JDK. It should fail if it isn’t but
> that isn’t the case yet and that isn’t your problem. It appears the RPM
> generated is 32-bit. Unless you are bundling a 32-bit JRE and the RPM
> bundler keys off the native libraries used. Can you check the launcher
> executable? I think it’d be:
> >
> > $ file myserver-1.0-1.x86_64/app/myserver
>
> I had to extract the launcher from the .rpm.  There is no version of it
> that is sitting around in the output folder.
>
> myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked (uses shared libs), for GNU/Linux 2.6.15,
> BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped
>
>
> So the 64-bit launcher is bundled.
>
>
> >
> > Can you file a minimum test case along with the Linux system used so we
> can prioritize with other bugs and find a solution?
>
> I’ll try to put something together.  I’m still eager to find a workaround
> that I can implement with 8u72.
>
>
> Scott
>
>
> >
> > Chris
> >
> >
> >> Scott
> >>
> >>
> >>> On Feb 2, 2016, at 7:03 PM, Chris Bensen 
> wrote:
> >>>
> >>> This list or the Deployment blog (
> https://blogs.oracle.com/talkingjavadeployment/) are the best places to
> get help with the javapackager.
> >>>
> >>> Is your app built with the 64-bit or 32-bit packager? I noticed
> “x86_64” appended to the name. If it’s 32-bit you could try running:
> >>>
> >>> sudo apt-get install libx11-6:i386
> >>>
> >>> Chris
> >>>
> >>>
>  On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
> 
>  What's the best place to go to get help with using the javapackager ?
> 
>  I've read the docs, but things aren't working smoothly and it would be
>  helpful if there were some known working examples to base things on.
> I'm
>  not finding any examples that use the -daemon or -BserviceHint=true
>  options, for example.
> 
>  I attempted to make a .rpm that installs a service/daemon but when I
> try to
>  install it, it fails claiming the following dependencies cannot be
> met:
> 
>  libX11.so.6 is needed by myserver-1.0-1.x86_64
>  libXext.so.6 is needed by myserver-1.0-1.x86_64
>  libXi.so.6 is needed by myserver-1.0-1.x86_64
>  libXrender.so.1 is needed by myserver-1.0-1.x86_64
>  libXtst.so.6 is needed by myserver-1.0-1.x86_64
>  libasound.so.2 is needed by myserver-1.0-1.x86_64
> 
>  Considering the app already runs fine on this same system, I'm a bit
>  confused that it is complaining of missing dependencies.
> 
>  Scott
>
>

Re: Remove a line from GraphicsContext

2016-02-04 Thread Bryan Buchanan

You're an absolute champion ! Thanks very much.

On 4 February 2016 at 18:10, Gerrit Grunwald  wrote:

> First it will be better using
>
> gc.strokeLine(x1, y1, x2, y2);
>
> To clear the line itself you could clear a rect around the line like
>
> gc.clearRect(x1 - 1, y1 - 1, x2 + 1, y2 + 1);
>
> Take a look at this Gist...
> https://gist.github.com/HanSolo/f25412352ff7ec5b9b53
>
>
> Am 04.02.2016 um 08:53 schrieb Bryan Buchanan :
>
> Don't know if this is correct mailing list.
>
> If I have
>
> gc.setStroke(Color.RED);
> gc.moveTo(x1, y1);
> gc.lineTo(x2, y2);
> gc.stroke();
>
> and later I want to remove this line, how do I do that ?
>
> I don't want to clear the whole the Canvas (in fact
>
> gc.clearRect(0, 0, canvas.getWidth(), canvas.getHeight());
>
> doesn't remove the line anyway).
>
> Also, if I wanted to implement a blinking cursor on a Canvas, is there a
> neat way to do that ?
>
> Thanks.
>
>
>

Re: Remove a line from GraphicsContext

2016-02-04 Thread Gerrit Grunwald

First it will be better using

gc.strokeLine(x1, y1, x2, y2);

To clear the line itself you could clear a rect around the line like

gc.clearRect(x1 - 1, y1 - 1, x2 + 1, y2 + 1);

Take a look at this Gist... 
https://gist.github.com/HanSolo/f25412352ff7ec5b9b53 



> Am 04.02.2016 um 08:53 schrieb Bryan Buchanan :
> 
> Don't know if this is correct mailing list.
> 
> If I have
> 
> gc.setStroke(Color.RED);
> gc.moveTo(x1, y1);
> gc.lineTo(x2, y2);
> gc.stroke();
> 
> and later I want to remove this line, how do I do that ?
> 
> I don't want to clear the whole the Canvas (in fact
> 
> gc.clearRect(0, 0, canvas.getWidth(), canvas.getHeight());
> 
> doesn't remove the line anyway).
> 
> Also, if I wanted to implement a blinking cursor on a Canvas, is there a
> neat way to do that ?
> 
> Thanks.

Re: javapackager

Re: Canvas Clip performance

Re: Canvas Clip performance

Re: Canvas Clip performance

Canvas Clip performance

Re: javapackager

[9] Request for review: 8143158 [Text, TextFlow] Make public API from internal "impl" APIs

Re: javapackager

Re: Remove a line from GraphicsContext

Re: Remove a line from GraphicsContext

10 matches

Site Navigation

Mail list logo

Footer information