[GitHub] [netbeans] timboudreau commented on issue #1278: [NETBEANS-2604] Support SVG icon loading from ImageUtilities

[GitBox <gi...@apache.org>]

timboudreau commented on issue #1278: [NETBEANS-2604] Support SVG icon loading from ImageUtilities
URL: https://github.com/apache/netbeans/pull/1278#issuecomment-498695420
 
 
   I don't seem to be able to add review comments here, so I'll just enumerate them:
   
   1.  For startup / loading performance, I would still advice compiling images into something vector-ish without the overhead of XML parsing at *compile time*, having the loader look for that first, and if that fails, *then* fail over to parsing SVG.  That's not a blocker, as it could be added transparently later, but probably a good idea.  Parsing XML is not cheap, and since icons are loaded on demand, it's not going to be predictable what it slows down, but it will slow down something.
   
   2. In GraphicsNode, you probably want to use the rendering hints for the specific screen type, so SVG icons use subpixel antialiasing if the user's screen does (this should also be incorporated into CachedImageKey, since the value may be different on one monitor and another, e.g. RGB vs. BGR).  You can get the screen settings like this:
   
   ```
   hintsMap = (Map<RenderingHints.Key, Object>)
       (Toolkit.getDefaultToolkit().getDesktopProperty("awt.font.desktophints"));
   ```
   
   3. I would go beyond in-memory caching, and actually use the IDE's cache dir to write out rasterized versions of the generated images, and attempt to load from there first - particularly if not doing any precompiling.  Just make the image size and other properties part of the path from your cache folder, e.g.  $CACHE_ROOT/svgimg/$WIDTH/$HEIGHT/$TEXT_AA/org/openide/resources/actions/redo.png - then let the original ImageUtilities raster image caching take care of it from there.
   
   
   The way you'd do that "compiling" would be to load the SVG and paint it into something like this:  https://github.com/timboudreau/imagine/blob/master/Imagine/vector/src/main/java/net/java/dev/imagine/api/vector/painting/VectorWrapperGraphics.java - and then have a simple way to serialize the list of objects that represent paint operations to disk;  and load those at runtime.  Or perhaps Batik's internal representation could be used in some tighter, more lightweight serialized form (but I doubt it, and it would be nice, under normal circumstances, not to load Batik at all).
   
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists