> 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.
Aren't NetBeans database connections stored in XML files? And editor color settings? And editor keybindings? > Can you cache PNGs at compile time? Compile time is tricky since we don't know the target scaling. We could do 2x and scale down at runtime for other scalings (e.g. 1.5x), but I don't think it will look as good as when you render directly for the correct scaling. And larger scalings (e.g. 3x, which is supported on Windows) would not look good. timboudreau's suggestion was to render at runtime, but cache rendered icons in the NetBeans cache directory, so the next time NetBeans runs, loading of the Batik libraries, at least, could be delayed further. -- Eirik -----Original Message----- From: Jaroslav Tulach <jaroslav.tul...@gmail.com> Sent: Saturday, September 26, 2020 12:28 AM To: dev@netbeans.apache.org Subject: Re: IDE Icon Registry (The SVG Story Continues) (AKA What about to clean up some mess) 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 <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 > > --------------------------------------------------------------------- > 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
