JDeps should recognize JavaFX internal API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! After the great news on JEP253 I wanted to play around with JDeps to identify the dependencies on internal API in, e.g., ControlsFX. Turns out JDeps does not recognize these yet: https://bugs.openjdk.java.net/browse/JDK-8077349 I think that's a serious shortcoming of this otherwise very useful tool. Many projects which are just now realizing how Project Jigsaw might affect them could turn to JDeps to identify problematic dependencies. If the tool only reports some of them, this could undermine its adoption or create a false sense of being well prepared. It would be great if those members of this list which are in the position to do so consider moving this issue forward, e.g. by upvoting. Thank you Nicolai Parlog - -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindexsearch=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVVaykAAoJEMo7rS6czNUJub0P/0tdfsI1sjv4653jW4Fc478M vCJbxCL5ym3/UCR9m2ql6Mt5XiY9M5pYU0BNLlw5wq8z02MYCTRB7U2jjtIyw2NY JCgBqg8y74QjNbJByKjHz+PoV/GYoUk23h/ERZPFs0x+KqH20JVGVKbfLuQEJUhd crDkrpju8K6QI0PIOIwjqN+M+Dcp7ROCflZcSlZO02QEgKldpJYEYyZg+IpnT7aC +vCJi10+7KkmDhDIPd81DQJAEicrnwkbFGUwlViylQkl5VZA3qq0p5BBdCKbIAuN KeMILjLYL6Kz8rzcvhl5oVdrEbauaI5NaEEhFVrD4Zf8HGYL6opXIrYLx6ZekTK5 rT1ChT9vDpUKcxwrI8mwT8hu7Wg/wcGgUHhxYM2NZQv87zih4UYSIcd/gb93xUfH meqHz79TEB5xi36RgpVKdUdMptdKgOB4N3Oo66XCtR6AkJo58LTLPvoFJmXX6kMd XaQBfW21oi8iayE7T17LbvG7xz76B1uZZb3L94e7UXycsodTBpjr6OLXzsutD4ht lk69HUKHsp/YTCGuXWsQ5en7QTASedN9TskE7ljnmQtUuGkVycanQzVZx+mdrjfx ZN2KTgytFxyD2ghUEQkIU8thFNxSlSHsJv0aaIZkK2kQ8yfIQLNOTfj8wSehIMEI wR/v5JCzPsvhp1ToQW63 =JjxD -END PGP SIGNATURE-
Re: slightly ot: java9 runtime images
Hi Tom, could you do this with File.deleteOnExit? Question is, can it delete jars on its own classpath... Werner On 14.05.2015 08:22, Tom Eugelink wrote: Unfortunately you cannot have the spawned JVM cleanup after itself, otherwise I could stop the initial JVM after it spawned the other.
[8u60, 9] Review request for RT-40778: BMP image fails to load when a specific size is requested
Jim, Could you please review the fix: https://javafx-jira.kenai.com/browse/RT-40778 http://cr.openjdk.java.net/~vadim/RT-40778/webrev.00/ Thanks, Vadim
Re: Maximum size of a canvas?
Hi.
The report can be zoomed in which basically means
that I recreate the canvas with a bigger size (the canvas is inside a
scrollpane).
Instead of creating an eventually (and quadratically) huge canvas,
you could try using Canvas.getGraphicsContext().scale(2 double)/translate(2
double),
and bind the scroll bars to the {canvas dimensions, applied transform} data.
-Jeff
In(Sanity) Testing Mondays
Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim
Re: Maximum size of a canvas?
Hi Jeff,
interesting idea although I am not sure in which way this improves
things. I am already scaling the canvas node if it is bigger than
necessary (due to previous zoom, works like supersampling then) or
smaller than necessary (if the maximum size is reached but I need to
present the content bigger than that).
Looks as if the scaling of the canvas and the scaling of the
graphicscontext might both be applied at the same time - unless one is
simply a shortcut to the other. I have to experiment on this one.
Rgds
Werner
On 15.05.2015 16:15, Jeff Hain wrote:
Instead of creating an eventually (and quadratically) huge canvas,
you could try using Canvas.getGraphicsContext().scale(2
double)/translate(2 double),
and bind the scroll bars to the {canvas dimensions, applied transform}
data.
Re: Maximum size of a canvas?
The Canvas is simply a texture of the specified dimensions. (We do
scale that size by any pixel scale applied to the entire scene, as in
Mac retina's 2x scale, but it's size is interpreted in the same
coordinate space as the Stage, Scene and the root Node coordinates.)
Transform properties on the Canvas Node (scale, rotate, translate, list
of transform objects) are applied to the pixels in the texture as they
are incorporated into the scene as if it were an Image.
Transform properties in the GraphicsContext are applied during rendering.
So, neither affects the other or is a shortcut to the other. They do
combine visually into the end product, but one is at the
rendering-into-the-texture stage and the other is at the
blit-texture-to-the-screen stage. Transformations applied to the Canvas
node properties can lead to pixel stretching artifacts...
...jim
On 5/15/15 8:02 AM, Werner Lehmann wrote:
Hi Jeff,
interesting idea although I am not sure in which way this improves
things. I am already scaling the canvas node if it is bigger than
necessary (due to previous zoom, works like supersampling then) or
smaller than necessary (if the maximum size is reached but I need to
present the content bigger than that).
Looks as if the scaling of the canvas and the scaling of the
graphicscontext might both be applied at the same time - unless one is
simply a shortcut to the other. I have to experiment on this one.
Rgds
Werner
On 15.05.2015 16:15, Jeff Hain wrote:
Instead of creating an eventually (and quadratically) huge canvas,
you could try using Canvas.getGraphicsContext().scale(2
double)/translate(2 double),
and bind the scroll bars to the {canvas dimensions, applied transform}
data.
Re: slightly ot: java9 runtime images
It tried every angle, including tempfile. Problem is that that the initial JVM creates the file, so it can consider it a temp file, for the spawned JVM it is an existing file. Tom On 15-5-2015 12:28, Werner Lehmann wrote: Hi Tom, could you do this with File.deleteOnExit? Question is, can it delete jars on its own classpath... Werner On 14.05.2015 08:22, Tom Eugelink wrote: Unfortunately you cannot have the spawned JVM cleanup after itself, otherwise I could stop the initial JVM after it spawned the other.
[8u60,9] review request: RT-39689: Better docs and error checking if Printing or Dialogs called from Animation
Phil, Please review the following: https://javafx-jira.kenai.com/browse/RT-39689 http://cr.openjdk.java.net/~kcr/RT-39689/webrev.00/ -- Kevin
