Eirik wrote: > > Sooner or later, the XML parsing architecture will be loaded anyway, no? > > Before the user can do anything useful with NetBeans?
Not really. You can connect to DB without parsing XML. You can open a TypeScript project without parsing XML. You can open a Gradle project without parsing an XML. While on performance team we fought hard to avoid - let's load all my functionality on startup attitude - no user of NetBeans is using all NetBeans functionality. True, when working with Maven, one needs to load the XML in anyway. > Well I like the idea of using annotation processing to define SVG-s and > place them inside a generated catalog. Just like there are public/private classes/package, there shall be public/ private icons. The fact that some module has an icon doesn't mean other modules can use it. One has to export that icon explicitly. > The implementation detail, whether we shall create some cached png-s in > compile time or, compile them into Java Graphich2D calls is indifferent > to me, probably it would just depend how much effort we can put into this. Recording/replaying Graphics2D calls has been done in the past by numerous projects. It's just a matter of which one to choose. Btw. Can you cache PNGs at compile time? As Eirik wrote: > > 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). and that seems to me like request to cache the PNGs at runtime. That would be a different story. > The one problem with @StaticResource is currently it does not take > account the module dependencies. I do not know if that's a feature or > just a shortcoming of the implementation. @StaticResource verifies that a resource is on your compilation classpath. That means it takes into account module dependencies. What exactly is the problem? -jt > It could be also fine for me if we do not move the existing images to a > central catalog by altering the ImageUtilities.getIcon(). We update the > module to use the catalog whenever we find the time for that. > > On 9/23/20 9:13 AM, Eirik Bakke wrote: > >> 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 > > --------------------------------------------------------------------- > 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
