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 >>>>> >> >
