== Precompiling > > As Tim points out we don't want to waste CPU/GPU time rendering > gradients for icons at runtime. > > We could define some "standard" sizes for icons and precompile them to > these sizes. Very much like native mobile apps do for Android an iOS. In > iOS, for example, they have @1x, @2x, @3x suffixes for different icons > sizes. > > That, of course will require a project/repository of its own. >
I don't think so, regarding a repo. Either: - Compile them to images of several sizes when building the module jar (from reading the comments in VectorIcon, it sounds like particularly on Windows hidpi, this can vary wildly, so I'm not sure this is a perfect solution), or - Compile them to a Java class that adds up to "painting instructions" (much faster load time and no dep on batik) - it's not that hard to write a Graphics2D implementation that outputs Java code for everything done to it, so you could load an SVG image into Batik, and have it paint into that and generate a class from the result); on first load, load it, paint it into a BufferedImage and save that to the IDE's cache directory, subdirectory by screen resolution, with the SHA-1 hash of the original SVG as the name. - Or, let the installer do this at the end of install - it actually knows the screen resolution likely to be needed, so that is the perfect time to do it, and let the IDE do the above for anything missing I don't think a repository just for icons solves much of anything, and probably creates some new problems. If you have a checkout of the IDE, `find . -name *.svg` does a fine job for locating everying; disconnect them from the code that uses them, and you're guaranteed to wind up with a pile of old icons used by nothing that nobody is sure if are unused or not. -Tim > > > == Standardizing > > If we're to precompile icons we may also want to standardize them > somehow. We could separate icons by cluster (in the repository above), > and create a cluster-specific module responsible for returning icons (of > appropriate size depending on DPI) for all modules in that cluster. > > The objective being making all "folder" icons look similar. We now have > blue folders and yellow folders all around. > > == Generating SVG from PNG > > See Tim's response in another thread [1]. I think Emilian set up a > website in 2017 to do this [2]. > > I don't think automatic conversion is worth the effort: we'll end up > having to fine-tune the results by hand, as Emilian tried to do back in > 2017. > > Also note that Adobe Illustrator seems to have a way to do this: > > https://www.lifewire.com/use-image-trace-in-adobe-illustrator-cc-2017-4125254 > > Cheers, > Antonio > > [1] > > http://mail-archives.apache.org/mod_mbox/netbeans-dev/201904.mbox/%3cCA+qecRNnE=L49v5t46q_LVc=rpTqJD3U7zt4-0DAroG=x6h...@mail.gmail.com%3e > > [2] > https://jaxenter.com/netbeans/netbeans-retina > > El 06/04/2019 a las 19:50, Tim Boudreau escribió: > > I did most of the icons in 1999 (a few of them still exist in core as > tree > > icons for nodes that are not typically shown anymore); in 2000 they were > > taken over by Sun's Human Interface Engineering team, and everything was > > converted to the (awful) "flush 3d" metal look and feel look. Circa 2004 > we > > got out from under the tyrrany of metal look and feel, and they were > > redesigned again by a guy whose name I can't remember, but could probably > > dig up - that redesign established the shapes still in use for things > like > > classes, fields and methods. Since then there was one reworking of the > > icons that made them more cartoonish (I remember Wade calling it > "NetBeans > > for babies"). > > > > I think in the long run, switching to vector icons is smart. That said, I > > would not run with SVG without precompiling it into code that drives a > > Graphics2D and either renders and caches images, or deals with > performance > > and memory allocation issues around GradientPaint and friends in the JDK > > (both allocate large rasters on every paint, and vertical and horizontal > > and radial gradients can be cached and reused instead - AND the pixel > > pushing approach of those has a serious impedance mismatch with modern > > graphics pipelines - it happens that just this week I benchmarked cached > > gradient BufferedImages vs GradientPaint and RadialGradientPaint with as > > much raster caching as you could do there - the result was blitting > > BufferedImages was 10x faster, and 40x faster if you ran a full GC > between > > benchmark loops, meaning that performance with Paint objects is also much > > less predictable). One of the rationales for JavaFX's creation was to > have > > a graphics toolkit that operated with the grain of how modern graphics > > cards work, rather than 1990s xterms did things. > > > > -Tim > > > > On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eba...@ultorg.com> wrote: > > > >> There are over 3000 bitmap icon images in the NetBeans codebase. > Probably > >> at least several hundred of these are frequently seen by everyday > NetBeans > >> users. The page below shows all the unique "gif" or "png" files that > >> existed in the NetBeans mercurial repo prior to the Apache transition: > >> > >> htps://people.csail.mit.edu/ebakke/misc/icons.html > >> > >> THE QUESTION: Does anyone know who actually designed and drew these > icons? > >> > >> I assume some were cobbled together from various sources, but on the > other > >> hand, many of the frequently visible ones (e.g. the ones in the > toolbars) > >> seem to follow a quite consistent visual style. > >> > >> (This question relates to the effort of making NetBeans look better on > >> HiDPI/Retina screens; see separate email thread.) > >> > >> -- Eirik > >> > >> -- > > http://timboudreau.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- http://timboudreau.com
