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 <jaroslav.tul...@gmail.com>
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: dev-unsubscr...@netbeans.apache.org
>
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> >
>
> > For further information about the NetBeans mailing lists, visit:
>
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
>
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
>
>
> For further information about the NetBeans mailing lists, visit:
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
>
>
> --
http://timboudreau.com
