On Thu, 22 Oct 2020 at 08:40, Eirik Bakke <[email protected]> wrote: > What's wrong with the idea of caching rasterized PNG files the first time > an SVG icon is loaded? (Also timboudreau's idea, from > https://github.com/apache/netbeans/pull/1278 .)
Hello, I just wanted to report our experience using the current SVG support in NetBeans (11.3): we are using around ~380 .svg icons in our NetBeans RCP application and we did not experience any problem of performance with the current approach. We even moved the org-openide-util-ui-svg.jar module and the Batik libraries in platform/lib to allow us to use SVG for the splash screen without any noticeable problem. What is interesting is the idea of an icons catalog API, we are already doing something similar to allow reusing the same icons in the whole application. Best, -Matteo > > > could result in much smaller files than either XML, or PNG/GIF > > Note that icons will end up being rasterized in memory in any case (for > compatibility with ImageIcon etc.). So in terms of memory consumption, you > won't beat the cached PNG approach. > > Aside: Did I manage to convince Jaroslav that XML loading infrastructure > will be loaded in the NetBeans no matter what, and can thus be considered > "free" from the point of view of increased startup time? (Since editor > color settings, editor keybindings, and other things must be loaded from > XML files before the IDE can do anything useful?) > > -- Eirik > > -----Original Message----- > From: Tim Boudreau <[email protected]> > Sent: Tuesday, September 29, 2020 8:41 PM > To: [email protected] > Subject: Re: IDE Icon Registry (The SVG Story Continues) (AKA What about > to clean up some mess) > > I have thought long ago that if we wanted to have svg icons in NetBeans, > we would be better off “compiling” them to a binary format that > encapsulates the drawing instructions (could result in much smaller files > than either XML, or PNG/GIF) - there are not many necessary bytes of > information in “move to x,y; set the color to...; draw a line to a,b”. > > I wouldn’t turn them into classes - how many icons do we have, and what’s > the footprint of one in the perm gen multiplied by that number? > > FWIW, I have the classes you’d need to do this “compiling” of svg - part > of imagine, which I use for the “native” file format for vector layers. > > -Tim > > On Wed, Sep 23, 2020 at 6:58 AM Jaroslav Tulach <[email protected] > > > wrote: > > > XML is bad. Does it mean that SVG is bad as well? > > > > > > > > XML, as implemented in Java with Xerces parser is a massive piece of > > software. > > > > It composes of about three thousand of classes. Does our current > > > > infrastructure for rendering SVG uses Xerces? That means we need to > > load all > > > > the infrastructure when drawing first SVG icon. That obviously has to > > slow > > > > NetBeans startup down. > > > > > > > > Once upon time an XML parser was necessary to start NetBeans (think of > > > > `layer.xml` files, of `config/Modules/*.xml` files, etc.). However > > when I was > > > > working on the NetBeans performance team, we eliminated all of that > > with > > > > caches. The goal was: No XML parsing on (second and subsequent) startup. > > > > > > > > Now, when we are switching to SVGs, we are reintroducing the Xerces > > overhead > > > > again. Can we avoid it? > > > > > > > > Here is a plan which, by a chance, also addressed the IDE Icon > > registry > > > > problem. Let's process the SVG icons during compile time and turn them > > into > > > > Java classes. Such technologies (based on Batik) exist (for example > > http:// > > > > ebourg.github.io/flamingo-svg-transcoder/) and it is just a matter or > > > > integrating them into our build system. Let's imagine an annotation > > processor > > > > to process @SVG annotation: > > > > > > > > ``` > > > > @SVG(resource="resources/wait.svg", className="GenericIcons") > > > > @SVG(resource="resources/wait-too-long.svg", className="GenericIcons") > > > > package org.openide.util; > > > > ``` > > > > > > > > That would generate a class like > > > > > > > > ```java > > > > public GenericIcons { > > > > private GenericIcons() {} > > > > public static ImageIcon wait() {...} > > > > public static ImageIcon waitTooLong() { ... } > > > > ``` > > > > > > > > The class would contain all the instructions `fillRect`, `arc`, > > `lineTo`, etc. > > > > in the form of Java code. The SVG files would be removed from our JARs. > > E.g. we > > > > would immediately solve the problem of comments, long meta-data and > > XML > > > > parsing. All the icons would be available as Java code, ready to run > > and ready > > > > to be GCed once no icon from a generated class is in use. > > > > > > > > In addition to that this class would hook into existing resource > > oriented API, > > > > so all icons could be referred via their location. Moreover we could > > also > > > > implement Tim's suggestion to hook into UIDefault resources with > > > > > > > > ```java > > > > @SVG(uid={"wait-icon"}) > > > > ``` > > > > > > > > The `GenericIcons` class could be in private packages, or it could be > > placed > > > > into public packages. Then it would form an API other modules can > > use[1] and > > > > could avoid the duplication of icons. > > > > > > > > Would that work? If so, and we can eliminate all the XML parsing on > > startup, > > > > I'd be in support of some form of SVG icon registry. > > > > > > > > Best regards. > > > > -jt > > > > > > > > PS: There is `@StaticResource` annotation currently, so there is no > > need to > > > > copy `wait` icon 30 times at various places even now... > > > > > > > > Dne úterý 22. září 2020 8:15:28 CEST, Laszlo Kishalmi napsal(a): > > > > > Dear all, > > > > > > > > > > We have about 4200 icons/images in the repository. most probably > > > many of > > > > > them are duplicates, triplicates, multiplicates copied to different > > > > > locations. > > > > > > > > > > Just in a recent PR, Eirik added 34 new svg icons to 192 places. > > > > > (https://github.com/apache/netbeans/pull/2387) > > > > > > > > > > We have 28 instances of wait.gif (and 4 wait.png). > > > > > > > > > > I think before jumping into the svg era, we need to stop, look > > > around > > > > > and think. Could we do better? > > > > > > > > > > I think, yes, there is a demand for a common icon catalog. Or more > > > icon > > > > > catalogs (per cluster?) > > > > > > > > > > I've done a very raw sketch to get the base of a discussion. It is a > > > raw > > > > > Idea I have in my mind: https://github.com/apache/netbeans/pull/2388 > > > > > > > > > > My two main goals: > > > > > > > > > > - Move reusable icons to a centralized place catalog. I'd imagine > > > > > these catalogs as public java Enums > > > > > - Provide backward compatibility based on icon resource names > > > > > > > > > > Feedbacks/requirements/insights are welcome! > > > > > > > > > > BTW, I'm completely Ok if we do not do anything about this. I just > > > > > wanted to draw some attention on this issue. > > > > > > > > > > -- > > > > > > > > > > Laszlo Kishalmi > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > For further information about the NetBeans mailing lists, visit: > > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > For further information about the NetBeans mailing lists, visit: > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > > > > > > > -- > http://timboudreau.com > -- Matteo Di Giovinazzo
