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 GraphicsContextInterface and drew to .svg files. A third group could simply plug the two together and get nice plots displayed on the Canvas or written to a .svg file without even starting up the GUI.
Instead I’ve got my basic plotting code (for rendering NMR spectra) and my own SVG exporter that only knows how to export the methods that I use in the plotting. Those two don’t lead to a whole ecosystem of tools that leads to great applications. Bruce > On Nov 2, 2020, at 6:07 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > 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 library > could do that just as easily. What you wouldn't get is standardization of > that interface. > > -- Kevin > > > On 11/2/2020 2:34 PM, Bruce Johnson wrote: >> 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 question. >> Libraries like VectorGraphics and JFreeSVG are really useful for actual real >> world applications and I don’t see comparable tools appearing for JavaFX >> without some changes like I propose (or better ones than I can think of). >> >> Bruce >> >> >> >>> On Nov 2, 2020, at 5:04 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> >>> wrote: >>> >>> 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 class and interface) is a reasonable >>> approach. >>> >>> -- Kevin >>> >>> >>> On 11/2/2020 6:58 AM, Michael Paus wrote: >>>> 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 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 complete scene graph to another device (vector graphics >>>>> files etc.) >>>>> >>>>> Bruce >>>>> >>>>> >>>>>> On Nov 2, 2020, at 9:17 AM, Michael Paus <m...@jugs.org> wrote: >>>>>> >>>>>> 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 where JavaFX already exists >>>>>> and can be used. Just think of the Android canvas or, via cross- >>>>>> compilation, even the HTML 5 canvas. >>>>>> Just my two €ent. >>>>>> Michael >>>>>> >>>>>> Am 02.11.20 um 14:18 schrieb Bruce Johnson: >>>>>>> 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 (.svg, .pdf, etc.). >>>>>>> >>>>>>> The GraphicsContext class of JavaFX serves a similar function to >>>>>>> Graphics2D of java.awt, but because it is a final class it cannot be >>>>>>> extended to create similar functionality as found in VectorgGraphics or >>>>>>> JFreeSVG. >>>>>>> >>>>>>> This is a serious limitation (at least as far as I can tell) to JavaFX >>>>>>> applications. It would be highly desirable to be able to redirect >>>>>>> drawing on a Canvas to other output formats such as vector graphics >>>>>>> files (.svg, .pdf etc.). >>>>>>> >>>>>>> I currently work around this by using composition. I have a Java >>>>>>> interface that has most methods of GraphicsContext. Then a >>>>>>> GraphicsContextProxy class implements the interface and contains an >>>>>>> instance of GraphicsContext. This class is used for drawing to the >>>>>>> Canvas. I’ve then created a SVGGraphicsContext and PDFGraphicsContext >>>>>>> that implement the interface and these can be used to draw to .svg or >>>>>>> .pdf files. >>>>>>> >>>>>>> This works, but means that all code that draws on the canvas has to be >>>>>>> rewritten to take the GraphicsContextInterface rather than the normal >>>>>>> GraphicsContext. >>>>>>> >>>>>>> It would be much simpler if >>>>>>> 1) GraphicsContext was not final and could be extended. >>>>>>> or >>>>>>> 2) A GraphicsContextInterface existed that GraphicsContext >>>>>>> implemented. Developers could then have alternative GraphicsContext >>>>>>> implementations that implemented that interface. This would require >>>>>>> canvas drawing code to be written to use the interface, but would still >>>>>>> be very useful. >>>>>>> >>>>>>> Either solution could (I think) be easily implemented in JavaFX without >>>>>>> breaking existing code and add a significant advance to the toolkit. >>>>>>> >>>>>>> If there are alternative solutions to the problem, that would allow >>>>>>> exporting canvas drawing to vector graphics files without requiring a >>>>>>> change to the code that draws to the canvas, I’d appreciate hearing >>>>>>> them. >>>>>>> >>>>>>> — Bruce >>>>>>> >
