> 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 <eba...@ultorg.com> Sent: Wednesday, September 23, 2020 12:04 PM To: dev@netbeans.apache.org 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 <jaroslav.tul...@gmail.com> Sent: Wednesday, September 23, 2020 6:59 AM To: Apache NetBeans <dev@netbeans.apache.org> Cc: Laszlo Kishalmi <laszlo.kisha...@gmail.com> 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: 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 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: 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
