Improving Eclipse Icon Scaling by Supporting Vectorized Icons #1438
Comments
|
Thanks. SVG support for icons would be really great. IIRC @HeikoKlare did also mentioned this in the past |
|
Yes there were discussions about this at the most-recent community meeting that @HannesWell hosted last week |
|
Thank you @Michael5601 for working on this.
Yes. I captured the meeting-minutes at At the very top of this page is also a link to the calendar that contains the dates of the upcoming meetings including the details how to join. |
|
I have already investigated (and implemented) SVG support a while back for SWT so here are some hints if some wants to go in that direction further:
So for my usecase I finally ended up in having a script that automatically generates the icons from a SVG using Inkscape (what is the only descend SVG render I know about) and place them in the bundle, this increases the size a bit but gives the best, reproducible and portable result. |
Thank you so much for your feedback - it’s very helpful :) |
You remember correctly. I have the pleasure of supervising Michael's work 🙂 I agree with Hannes that this issue should be placed in the SWT repo, as, in a first place, it will have to be addressed in SWT. And it might also be of interest for other SWT users than the Eclipse platform. Actually, the issue itself is not that interesting (as the "limitation" is commonly known), it is rather about informing that someone is working on that (to avoid duplicate work, be able to give feedback etc.). And if someone really wanted to start working on this, they will know or identify soon that this has to be addressed in SWT and (hopefully) have a look in the issue list of that repo. Thus, I will move that over to SWT. |
It that script publicly available. And if now would you mind sharing it? |
It is not public and rather roughly put together, something similar is already available here: https://github.com/eclipse-platform/eclipse.platform.images/tree/master/org.eclipse.images.renderer in my case it just a bit more automated, it first calculates all NxM variants for desired zoomfactors, then check if the source SVG has > modification time than target (or target do not exits) and then creates the PNG in a corresponding folder structure recognized by Eclipse. So in this case instead of calling |
|
FWIW, given the current state of the discussion, I would challenge those 2 initial assumptions (the bold parts):
PNG are sustainable enough, as they have been doing a good work for a decade. The issue is indeed that there are higher DPI nowadays and we miss support for those. But higher resolution PNGs would be sustainable for those higher resolution. As highlighted in previous comments, directly rendering SVG with SWT is far from being trivial, is an expensive task to develop and then maintain, that contain a big part of "risk". So IMO, the most promising step forward (currently), it to improve the process. With that, RCP adopter and users could generate and use the icons of their favorite size much more easily. That wouldn't be perfect, but this had the advantage of being possibly much easier to setup (as it's not part of SWT, it doesn't even need to deal with release process and so on) and to provide a big chunk of the desired value. This has IMO a much higher ROI and is less risky than trying to render SVG with SWT. |
|
I just wanted to add, that in general Icon-Fonts (even colorful) are actually a better fit for icons and state-of-the-art in web UIs, I though I added support for such kind of images to SWT a while back (but seems not finished / merged this due to low interest and/or contribution barriers at that time). Here is an example where I use the "locked" icon drawn as a font Unicode Symbol U+1F512 „🔒“ and I can get it at any scale on any background. |
Stating that something is good enough because it was good enough for some time is a risky argument. This may be true in case the requirements are still the same, but in this case, the requirements have changed. Of course, generating more PNGs and doing that in a more automated way would be a step forward. But in my opinion, it hides the actual problem. And while all the technical insights are very, very valuable, they should not be taken as arguments for making conceptual considerations and decisions. Let's phrase the problem a bit differently: there is a (current and even increasing) demand for the ability to retrieve an image (usually an icon) in an arbitrary size. The current way to deal with this is to provide more pre-generated icons for more sizes. For a long time, the assumption that you know at generation time of these images which sizes of the images will be required held true. For that reason, it was sufficient to provide 16x16 and later 32x32 icon images (and maybe even more today). But requirements have changed and will change even more in the future. We see more demand for customizability, such as better HiDPI support, also for the Windows 25% steps or even the experimental 1% steps, and maybe even for further customization of sizes in the UI on its own. This requirement can, conceptually, not be properly addressed with pre-generated images of fixed sizes. You may come to solutions like providing proper answers for every possible request in a specific range (e.g, for icons between 100% and 400%), thus storing 49 PNGs to deliver every size between 16x16 and 64x64. But that's probably not a good solution. This new requirement (being able to retrieve an icon image for an arbitrary size) demands for icons being generated out of an size-independent representation (such as a vector graphics) at request (and not before application delivery). This does, of course, not prevent you from considering different technical and more fine-grained design options to address specific problems, e.g., doing some caching of already generated images to improve performance.
Icon fonts are of course an even better way to provide icons and go beyond the usage of vector graphics. From the perspective of the overall goal, it should definitely be the preferred solution. But changing icons to icon fonts is a more invasive approach that will probably also require more adaptations at the client side than simplify replacing a |
|
That's why I said PNG (even with it shortcommings) is the most portable way. Rendering images on demand again opens a another can-of-worms, e.g different (os specific) anti-alising, roundings and so on, so everything has it shortcomminds. That's also the reason I believe SVG support can only be archived on the native level, because that's what SWT claims to use and we can always argue it is like it is implemented in the OS if it looks different.
Technically one can use image-maps that store different sizes in one file if its just the number of files that scares :-)
I once suggested that SWT ships with some well known fonts like AWT, Jface already maintains a list of "cross platform names" I just wanted to mention this as an alternatives if we talk about icons (e.g. Eclipse platform can deliver its own font for sure... also plugins like JDT/PDE ...) |
I have to admit that I don't get these points and they somehow also sound contradictory to me. The PNGs that we ship right now are rendered out of SVGs with some library. Why should it make any difference if I render the images with that library on-the-fly compared to doing that before application deployment and then simply reloading the persisted result (i.e., the PNGs)? And on the other hand: why should I want to have OS-specific anti-aliasing or the like? This is currently also not the case, as images are pre-generated in a uniform, OS-independent way. Regarding the second statement: I do not see why SWT should claim that it uses native SVG rendering support. I think you mean that SWT claims to adapt native widgets, but why should that cover using native SVG support given that is no existing SVG support at all? And finally: why should anyone care? If our customers would not like how our applications looks like, we can tell them that our products look like they look because it they are based on Eclipse (and that in turn on SWT, and that in turn on the OS). They would still not like how the application looks like, as they don't care which decision, i.e.g, which dependency is responsible for that. |
|
Here are some points
Please do not focus on changing the Image dynamically. The use case is pretty limited. Only couple of use cases I can think of
Please target ability to create raster images by loading SVG files with target size(this should be calculated based on the size in points multiplied by scalefactor). Need to enhance ImageData class. This will go a long way in rendering sharp images in Eclipse. Loading of Image should follow this preference
|
Please consider that the intended work is part of a bachelor thesis as noted initially. In that context aiming for the technologically and thus academically more interesting goal is IMO totally fine, even if the invest and risk is higher (ROI is usually only a secondary goal in academia). |
OK, I had missed that point. In such case, I agree that directly aiming for runtime SVG support in SWT is better topic for a bachelor thesis. |
|
As I work on this issue, I’d like to provide an update on my analysis progress. To date, I’ve completed an in-depth review of suitable Java libraries for vector graphics rasterization at runtime. The research is limited to java libraries because they would be easier to integrate into eclipse later on. Four libraries were analyzed:
Each library was evaluated using 11 metrics across five categories: functionality, performance, compatibility, maintenance state, and licensing. In this post, I’m presenting key findings from the six most important metrics, organized by section. FunctionalityI tested the libraries' functionality using vdiff, a tool enabling manual testing with various test suites. I tested with the following test suites:
The first two diagrams below show the pass rate for each test suite. The third diagram compares the results that I gathered to an analysis that was conducted by the author of resvg with the resvg test suite: 
Additional Findings
PerformanceUsing Java Microbenchmark Harness (JMH), I conducted performance benchmarks. Each benchmark tested the rasterization of 20, 50, or 100 Eclipse icons across target sizes (16x16px, 32x32px, 64x64px), resulting in nine benchmarks per library. Each benchmark was run 100 times, with results normalized to reflect the rasterization time per icon (e.g., dividing the results of the first benchmark (20 icons, 16x16px) by 20). This allowed me to combine the results for every size, which results in 300 iterations per size. The following four diagrams with boxplots summarize each library’s performance by icon size, with 300 data points per plot. A fifth diagram compares all four libraries on rasterizing all unique Eclipse icons (1,825) at 32x32px with 20 data points per plot. The dotted line in the boxplots is the mean and the solid line is the median. 
Performance Notes for first 4 diagrams:
CompatibilityFor compatibility, I assessed each library's dependencies:
Maintenance StateI measured maintenance frequency by the average time between releases, starting from version 1.0. For svgSalamander, I calculated only from GitHub releases starting 2016 due to the lack of SVN history.
Summary of Maintenance Findings:
LicensingLibrary licenses are as follows:
All licenses are compatible with the Eclipse Public License. ConclusionAlthough JSVG does not achieve the highest functionality scores, it excels in performance, lacks dependency issues, and shows robust maintenance support. EchoSVG, while functionally strong, is slower and has dependency issues. Apache Batik shares dependency concerns and is also slower, with less frequent updates. svgSalamander scores lowest overall, with limited functionality and discontinued development. Based on these findings, JSVG is the most promising option for Eclipse integration. Additional non-Java libraries are not necessary at this stage. I welcome any feedback or ideas on this topic. My next step is to begin integrating JSVG into Eclipse. If you’d like to see the complete analysis chapter from my thesis (in German), please reach out, and I’ll be happy to share it. |
Did you find out what this happens? Is that happening to only this one icon? |
|
One point that has been missed from product POV: |
|
Just as a side remark: AFAIK Batik is also used in the images repo's renderer. If we really go for SVG support in Eclipse via one of these libraries we should also think about using the same library in this renderer. |
If the images repo will still exist in its current state, I agree. But wouldn't SVG support in Eclipse render the repository obsolete, or at least make the PNG images inside the repository obsolete? |
It seems like the renderer is not used nor included by Platform. Only the CSS subcomponent (which is used by the renderer) and its basic dependencies seems to be there. The SVG bundles of batik are not even part of the p2 repo produced by Platform. |
Yes that's true. We could think of removing the PNGs from the images repo. |
That's exactly why I said "dependency concerns should be lowered" and not "removed". Now I looked more into it more and JSvg (https://mvnrepository.com/artifact/com.github.weisj/jsvg/1.6.1 ) is not osgi library nor in Orbit while batik-transcoder is available at https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/milestone/latest/index.html . So from releng POV JSvg will be more work as it will either have to be OSGified upstream (preferably!) and once such release is done to use it in Eclipse or it will have to be added to Orbit while batik transcoder can be "simply" reused from Orbit as it's already there. |
I'm not sure why this is happening, but I noticed it with certain items while testing with vdiff. Initially, I thought the program was making them blurry, but that wasn’t the case—it simply loaded the PNG at its original size of 32x32 pixels. |
No these four icons were broken generally, so it had nothing to do with the functionality of the libraries. The percentage of eclipse icons that are not properly rasterized still remains the same. For JSVG this means that 17 SVGs need to be adjusted to be properly rasterized. |
Thanks for the great input! I already thought that introducing the dependencies would be a problem but I was not aware that Batik is already included somehow. The implementation work that I do right now is independent of any library even though JSVG is the library that I test the implementation with. This means that in the end the library can easily be changed while still using the same place for the implementation. |
Which SVGs are these. And do you know that needs to be changed? Maybe we can improve them already. |
So the existing PNGs are blurry not the result of your SVG-rasterization? In that case we maybe can improve the existing PNGs. |
yes exactly. |
If you provide Issues for that I might have a look at them |
Here is a list of the icons. These are 22 icons from which I thought 17 were unique items, this is why I said 17 icons need to be adjusted. Actually only 15 icons are no duplicates. Additionally the icons often share the same problem. duplicates: duplicates: duplicates: not duplicates but have the same problem: not duplicates but have the same problem: not duplicates but have the same problem: org.eclipse.jdt.ui/icons/full/obj16/envvar_test_obj.svg not duplicates but have the same problem: duplicates: org.eclipse.ui.intro.universal/themes/solstice/graphics/launchbar/webresources16.svg I will provide issues in which I describe how to fix these icons for JSVG after I implemented it in Eclipse. |
That's very kind of you. Unfortunately, I didn’t write them down, but I’ll look for them. |
Sounds reasonable. |
No hurry. |
Assuming that the capability to render SVGs should be implemented in SWT directly and given that SWT should work in non OSGI runtimes as well and especially used to be one artifact (or in OSGI runtimes two), have we considered to embedd the jsvg jar or to shade it's content into into the SWT jar? But if we are fine to introduce a dependency I'm happy to help OSGI-fying it. Given the project I'd interested in such change it's usually simple and I have done it already a few times. |
That's something we discuss discuss since, if I am not mistaken, this would be the first "explicit" dependency of SWT. We should at least discuss whether it wouldn't be better to provide a hook for SVG rendering and provide the rendering capabilities separately, so that consumers can decide on their own whether they want to integrate it in their applications or not. The Eclipse RCP could then hook the functionality in by default. |
|
For your information I refer to an idea employed by the Haiku Vector Icon Format and Haiku's built-in tool Icon-o-Matic, namely the idea of allowing for icons with a different level of detail depending on their display size. |
Thanks for the info. The Haiku Vector Icon Format looks very interesting but I see two challenges that would be faced in the context of Eclipse:
Additionally we don't know right know how slow the rasterization is. I will provide performance measurements for starting an Eclipse application with and without SVG rasterization soon. |
I mention the Haiku Vector Icon Format solely for its level-of-detail feature that allows for multiple icons that are the "same" but have a different level of detail depending on the pixel size in which they are rendered. In the context of this issue, this feature can be implemented in some icons by somehow providing for multiple SVGs for the "same" icon that differ depending on their "pixel size", not necessarily by converting all vector graphics to the Haiku Vector Icon Format or a similar binary XML format such as EBML. (I don't suggest that SWT use the Haiku Vector Icon Format or any other binary vector graphics format, especially if the usual text SVG format is fast enough for SWT's purposes.) Having multiple SVGs of this kind can be useful not only for performance reasons; for example, it would be possible to design vector icons such that the smaller versions lack finer details that wouldn't be seen. |
For the PNGs this today this is technically already possible. We could keep that freedom by also allow to providing: |
Eclipse also support One can of course try to do a binary search for find the best fitting SVG... |
Eclipse currently relies on PNG files for displaying icons, requiring two different sizes to handle various zoom levels. For zoom factors between 100% and 174%, the original-size icon is used, while for zoom levels between 175% and 200%, a double-sized icon is displayed. This approach has several drawbacks:
Quality Loss with Autoscaling: Enabling autoscaling for icons using the flags
-Dswt.autoScale=quarteror-Dswt.autoScale=exactcan cause quality degradation, particularly on high-DPI displays or at high zoom levels, since PNGs do not scale well.Maintenance Challenges: Maintaining multiple PNG versions in different sizes is not a sustainable solution, especially as higher DPI displays may require even more icon variations.
Currently, new icons are manually created by converting SVGs to PNGs, a process that is both time-consuming and inefficient. By fully utilizing SVGs, which support resolution-independent scaling, these problems can be effectively addressed.
Previous discussions have highlighted these issues, such as those documented in this Eclipse bug report.
My bachelor’s thesis explores how SVGs can be better integrated into Eclipse to improve icon scalability and reduce maintenance overhead. If you have any insights or suggestions, please feel free to reach out or leave a comment!
The text was updated successfully, but these errors were encountered: