Community
Participate
Working Groups
Possibilities include: - Improve performance of SVG transcoder to render directly to SWT image instead of converting from BufferedImage - Case for when you are rendering a large image as a background for a diagram editor. Perhaps we also need to optimize the RenderedImage class to support a partial rectangle such that we only end up rendering a portion of the image based on the viewport.
Ideally, it would be great if instead of using images at all, you would draw directly to the SWT GC. This was not possible in previous releases of SWT. Now with SWT 3.1's addition of advanced graphics support this is doable. Batik has a class that you can fill in with the primitives needed to do this. Refer to DefaultGraphics2D http://xml.apache.org/batik/javadoc/org/apache/batik/ext/awt/g2d/DefaultGraphics2D.html
As an aside, I think BIRT has a SVG renderer/exporter. There may be opportunities for code reuse between the two projects.
Changing component to "Runtime Diagram"
I will improving the test for SVG method in RenderedImageFactory. I noticed that the SVGImage keeps an XML Document and the byte array buffer (from AbstractRenderedImage) of the original XML document stream in memory (twice the memory for one SVG). The XML Document might need to be a WeakReference to save on the memory or maybe keep an URI of sorts. The byte array buffer is keeping the entire XML documents' contents in memory (which could be quite large). Maybe we could use some form of InputStream/Reader implementations so that data is kept only in memory on- demand and then released. We could keep SWT images in memory (because they appear in the UI) and the fileName/URI. A new InputStream/Reader could be opened to perform any required operations on-demand.
Delivered to head: General performance improvements to the RenderedImage infrastructure: - Avoid recalculation of buffer checkSum on rerender of image - Cache SVGDocument on first render to avoid recalculating it on subsequent renderings. - Improved conversion of BufferedImage to swt Image. - Removed buffer copy in AbstractRenderedImage - Removed redundant copy of BufferedImage in ImageTranscoderEx - Improved caching in ScalableImageFigure to minimize re-rendering Achieved approximatly 25% improvement in performance for subsequent re-renderings of an SVG. Still to do (investigate): - allow extensibility of RenderedImageFactory - asynchronous rendering - remove java.awt dependency from root infrastructure. - separate awt components into different plug-in
added api keyword
Description: Some improvements to the SVG rendering capability in GMF to support: - asynchronous rendering of SVG files to avoid locking up the UI during rendering operation. - removing of java.awt package dependency from the root and public classes to enable future plug-in separation and extensibility of the RenderedImage infrastructure. - allow maximum rendering size to avoid rendering a huge image unnecessarily. This is useful for display. Summary of changes: (Old api is currently preserved in deprecated form) - Subclass RenderedImage interface from IAdaptable to allow implementors to adapt to different image formats. Specifically this allows the removal of the getBufferedImage method and instead clients can call getAdapter(BufferedImage.class) instead. Or if native rendering support to BufferedImage isn't supported clients can use ImageConverter.convert( myRenderedImage.getSWTImage() ). - RenderInfo#getFillColor and RenderInfo#getOutlineColor have been deprecated and replaced with replaced by getBackgroundColor and getForegroundColor respectively. They return RGB values. - RenderInfo#setValues(int width, int height, java.awt.Color fill, java.awt.Color outline,boolean maintainAspectRatio,boolean antialias) is deprecated and replaced with RenderInfo#setValues(int width, int height, boolean maintainAspectRatio, boolean antialias, RGB background, RGB foreground). Note: color parameters have been moved to the end of the method signature to avoid ambiguous null parameters and to group other parameters more appropriately.
Users of ScaleableImageFigure should benefit from these changes
Refer to bugzilla 119319 for handling the following: - allow extensibility of RenderedImageFactory - separate awt components into different plug-in
I may re-open this or create another bugzilla to address rendering directly to an SWT image instead of the indirection we have now. Apparently there is an example of how to accomplish this in the PrintTranscoder file.
Steven, Would it be possible to generalize this, or include an option to reder the SVG directly onto an SWT Canvas (instead of Image) for inclusion in a View or Editor? For the past three years I've been using the j2d4swt plugins from www.holongate.org to create Eclipse viewers for SVG graphics. These low-level SWT graphics are not my forte, but I'd be very interested in contributing where I can to create a reusable SVGCanvas for presenting SVG documents. As part of this, I need (and have implemented) mouse listeners for detecting click regions on the canvas by using the Batik SVGDocument.
Yes, it looks like that is possible. I'm experimenting with rendering the SVG directly to an swt Graphics object. If this is successful, then there is no need for the indirection to an Image (though it would still be supported). I would probably extend the RenderedImage api to have a render(Graphics g) api in order for this to to work. In future, if the RenderedImage infrastructure is integrated into GEF, the Graphics api could support it directly.
Ok, this is a sorta way out there comment, but if rendering directly to a Graphics object is possible - would it be possible at all to create Figures out of the SVG?
I think that's what ScaleableImageFigure satisfies. Even if I'm successful, directly rendering to the Graphics object, it wouldn't change the usage scenario for ScaleableImageFigure. It would merely improve rendering performance.
Great, thanks! Please ping this bugzilla (or my email) when something is checked into CVS for rendering to Graphics, and I'll try some experimentation. I may have other requests for API to enable an SVGCanvas with mouse event listeners, e.g. public access to the loaded SVGDocument instance. Is there any timeframe for integrating RenderedImage with GEF? Is this possible in the GMF 1.0 release timeframe?
I've created a new delegator class: Graphics2DToGraphicsAdaptor that allows the Batik renderer to paint directly onto an SWT GC. This improves rendering performance by up to 50%. It currently delegates directly to an swt GC instead of the draw2d Graphics class because draw2d doesn't expose all the capabilities of advanced graphics such as Transform. This means we still have a level of indirection through the SWT Image before rendering in the draw2d world. Once this is resolved, then performance could be improved even more by exposing an api on RenderedImage to draw on a Graphics directly.
[target cleanup] 1.0 M4 was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug
