Hello Tim.
> 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”.
Right.
> 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?
What do you want to generate then? My proposal would be:
An Icon == one generated method. All icons in a single package end up in the
same class.
Is that OK?
> 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.
Great. Can you turn that into a PR?
The PR could introduce an annotation processor to process an annotation like
```java
@SVGRegistry(class="MySVGRegistry", icons = {
"resources/icon1.svg",
"resources/icon2.svg",
})
package my.pkg.in.my.module;
```
I'd place the processor to https://github.com/apache/netbeans/tree/master/
platform/openide.util.ui.svg module. The module seems to have all the
dependencies on batik libraries. Every module offering SVG would depend on this
module then.
Tim, if you donate the SVG => Java code processing, then the rest (e.g.
integration with existing rendering system) shall be easy! Thanks in advance
for making NetBeans better (again)!
-jt
> 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
---------------------------------------------------------------------
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
