I would totally support this request from Bruce. I’ve implemented a number of
libraries (JFreeSVG, OrsonPDF, FXGraphics2D and SWTGraphics2D) on top of the
Graphics2D API, as have others. The Java2D engineers got this right back in
1999!
All it needs is an API (interface) that users can code a
On Mon, 2 Nov 2020 01:20:53 GMT, Thiago Milczarek Sayao
wrote:
> Simple fix to not build with GTK+ greater than 3.8 symbols.
Looks good. In general we shouldn't use compile-time version checks for OS or
platform software, since the binaries we produce should run on anything greater
than the m
But standardization of the interface is they key. I can imagine one group
writing a really useful charting library that just took a
GraphicsContextInterface and used it to render to the canvas. Someone else
could independently develop something like JFreeSVG that took a
GraphicsContextInterfa
I can see how this could be useful to a certain class of applications,
but I'm not convinced there is enough value, since the work that the
application would need to do is pretty much the same even if we added
the ability to subclass. As for providing an interface, I think that a
third-party li
The bug reports are great, thank you.
Aside from philosophically voting up the issue not sure what else I can add.
Here is the (somewhat amusing) workaround thread from StackOverflow:
https://stackoverflow.com/questions/64616443/how-to-get-awt-window-for-javafx-stage/64651359#64651359
Cheers,
-W
I should not even have mentioned the GraphicsContext for scene graph rendering.
There is something elegant about being able to easily make the whole scene
render to some other device/file, but I’m well aware of the practical issues.
But I do wish there was a better solution for the original que
Yeah, there is no chance we would consider changing the JavaFX to use
Canvas GraphicsContext for scene graph rendering.
As for the original question, we are unlikely to make GraphicsContext
extensible in the core JavaFX. I think the solution you came up with for
your application (with a proxy
For that API, you might consider using an AWT root Window with a JFXPanel
rather than a JavaFX Window to hold your JavaFX UI. But discussion of how
to code the application side is not relevant for this list.
For the record here are the relevant JavaFX issues:
https://bugs.openjdk.java.net/browse/
On Mon, 2 Nov 2020 12:47:06 GMT, Kevin Rushforth wrote:
> Bump the boot JDK used to build JavaFX to 15.0.1. This does not change the
> minimum boot JDK which remains at JDK 11.
Marked as reviewed by jvos (Reviewer).
-
PR: https://git.openjdk.java.net/jfx/pull/347
Looks like a nice and useful project! But,I’m looking for something specific
to the JavaFX canvas and that doesn’t require use of java.awt. There are many
examples of code that has been built on top of java.awt.Graphics2D (like
yours), but this doesn’t seem to be possible with the JavaFX Graph
On Fri, 23 Oct 2020 08:32:59 GMT, Jose Pereda wrote:
> As discussed in the [JBS
> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
> already snapped value (either intentionally or by mistake), the result
> should be the same, otherwise we'll be jumping unnecessary fr
Eclipse probably handles the modules differently than Gradle.
The simplest solution would be to remove the code to automatically create
heap dumps.
Adding java.management to module-info of the tests doesn't sound wrong to
me if it's using it.
On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth
wrote:
>
What Window should I pass in for the setWindowProgressState window
argument? It requires a java.awt.Window?
On Sun, Nov 1, 2020 at 5:48 PM Scott Palmer wrote:
> They work fine. Just remember to use the Swing/AWT event thread to call
> them.
>
> Scott
>
> > On Nov 1, 2020, at 8:39 PM, Will Ivers
On Mon, 2 Nov 2020 13:07:11 GMT, Johan Vos wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply fix to snapPortionXX methods, extend test.
>
> Looks good now.
Please go ahead and integrate with the current approva
At this point I would disagree with you. Doing so would just
result in a sever performance hit. I will not go into the details
here because that idea is out of reach anyway.
Am 02.11.20 um 15:42 schrieb Bruce Johnson:
And if you want to think of even further advances (which I’d avoid at this
po
And if you want to think of even further advances (which I’d avoid at this
point because I’d like this to get done in a useful time frame), I’ve often
thought that all JavaFX scene drawing should use the Canvas GraphicsContext.
So with the changes I’m suggesting that would allow export of the c
I think were’ not too far different in our ideas, but I think the practical
odds of getting this implemented are much higher if the existing
GraphicsContext methods are the base for the interface I propose. I think (but
could be wrong) that in fact the GraphicsContext was modeled after the HTML
Hi,
I very much like the idea in general but I think it falls too short.
Such an interface should not be tied to any existing graphics
framework. Instead it should be just pure Java. This would allow
to write complex graphics rendering code for a lot of different
platforms and not only platforms w
On Fri, 30 Oct 2020 16:04:51 GMT, Ambarish Rapte wrote:
> Each test in RegionBackgroundImageUITest makes several calls to
> `robot.getPixelColor()` on App thread. Due to this each test requires more
> than **60** seconds for execution.
>
> Fix is to save a screen capture of Scene (on App threa
Hello, Ivhabe created some time ago an OpenSource project called
jfcClnvertercwhichvtefurect the Jz aFX calls to a Graphics2D context. I don’t
know if it answers at least partially to this need. The project is here:
https://sourceforge.net/projects/jfxconverter/
Hervé
Sent from my iPhone
> On
A variety of packages (for example, VectorGraphics or JFreeSVG) exist that
allow redirecting Java2D drawing to output other than the Java2D canvas.
These work by extending java.awt.Graphics2D. By passing the extended
Graphics2D object into a paint method, output can be redirected to a file
On Tue, 27 Oct 2020 12:56:28 GMT, Jose Pereda wrote:
>> As discussed in the [JBS
>> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
>> already snapped value (either intentionally or by mistake), the result
>> should be the same, otherwise we'll be jumping unnecessar
I didn't try it with an earlier JDK, but if it breaks when using JDK 11
it will need to be fixed.
-- Kevin
On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote:
just fetched the latest upstream master and getting compile errors
around xx.management packages (eclipse wants to add requires into th
Bump the boot JDK used to build JavaFX to 15.0.1. This does not change the
minimum boot JDK which remains at JDK 11.
-
Commit messages:
- 8255714: Switch FX build to use JDK 15.0.1 as boot JDK
Changes: https://git.openjdk.java.net/jfx/pull/347/files
Webrev: https://webrevs.openjdk
seems to be an Eclipse problem, compiling (and running tests in
controls) via gradle on commandline looks okay ..
Zitat von Jeanette Winzenburg :
just fetched the latest upstream master and getting compile errors
around xx.management packages (eclipse wants to add requires into
the modu
On Tue, 27 Oct 2020 12:56:28 GMT, Jose Pereda wrote:
>> As discussed in the [JBS
>> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
>> already snapped value (either intentionally or by mistake), the result
>> should be the same, otherwise we'll be jumping unnecessar
26 matches
Mail list logo
