SVG is a huge language, which incorporates large portions of CSS. No way you
can get all SVGs to display properly this way.
OK, I take that back, you could intercept calls at the Graphics2D API level.
But *so* much easier, and more reliable, to just cache PNG versions...
E
-----Original Message-----
From: Eirik Bakke <[email protected]>
Sent: Wednesday, September 23, 2020 12:04 PM
To: [email protected]
Subject: RE: IDE Icon Registry (The SVG Story Continues) (AKA What about to
clean up some mess)
That obviously has to slow NetBeans startup down.
Sooner or later, the XML parsing architecture will be loaded anyway, no? Before
the user can do anything useful with NetBeans?
Isn't it a lot better to have loading happen during startup, while the user is already
checking their email, fetching their cup of coffee etc.? Isn't this why we have
"warmup" tasks running to initialize the editor infrastructure and so on early,
before the user actually starts interacting with the IDE?
Let's process the SVG icons during compile time and turn them into Java classes.
It would be much easier to just generate PNG images from the SVGs, the first
time they are used. On any given computer, only one or two scalings are going
to be in use (e.g. 2x on all MacOS machines, and perhaps 1x for an external
monitor). See https://issues.apache.org/jira/browse/NETBEANS-3469 .
The class would contain all the instructions `fillRect`, `arc`, `lineTo`, etc.
in the form of Java code.
SVG is a huge language, which incorporates large portions of CSS. No way you
can get all SVGs to display properly this way.
-- Eirik
-----Original Message-----
From: Jaroslav Tulach <[email protected]>
Sent: Wednesday, September 23, 2020 6:59 AM
To: Apache NetBeans <[email protected]>
Cc: Laszlo Kishalmi <[email protected]>
Subject: Re: IDE Icon Registry (The SVG Story Continues) (AKA What about to
clean up some mess)
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
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [
X ܚX KK[XZ[
] ][ X ܚX P ] X[ ˘\X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
] Z[ ] X[ ˘\X K ܙ B B ܈ \ \ [ ܛX][ۈX ] H ] X[ XZ[[
\ \ ]
B Z K \X K ܙ ۙ Y[ K \ ^KӑU PS XZ[[ \ B B B B
---------------------------------------------------------------------
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
