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
