Eye Hurting Icons!

The icons on the left sidebar are not good on the eyes in V8 WIP, especially on my second monitor, they are slightly better on the laptop screen, but still not great, in V7 both laptop and monitor nice and crisp ! I’m sure I’ve seen this brought up not long back but couldn’t find the thread, screenshot attached

This one maybe:

1 Like

Hi Anders, yes they are not good :-1:

1 Like

I’ve added this thread to RH-74408 UI is blurry at 125% scaling
-wim

1 Like

I’ve complained about the fuzziness of the WIP8 icons several times in several threads. I understand Rhino has moved from bitmap icons to .svg. I thought .svg was supposed to offer more precise and sharp images? The WIP8 icons look bad compared to V7 on all my machines and monitors.

1 Like

Your display will always have a grid of pixels in the end. Vector (or bitmap) graphics must always adapt on this pixel grid somehow. If the alignment is not perfect, you will have blurry icons.

Non-integer scaling and low pixel density will always be somewhat compromised solution. In my understanding, Rhino would need different set of pixel perfect icons for all non-integer scaling levels. And having a different set of icons will kinda miss the whole point of having Scalable Vector Graphics (SVG’s) in the first place.

I do hope that at least default size icons will look sharp on Apple hardware in Rhino 8 for Mac.

I’m sorry but that is BS. If that were true all the text you read on your computer would be blurry. Computer text usually is defined as curves that are converted on the fly to small bitmaps. It is done that way to save on storage space and so that the text will appear legible and clear when scaled to the desired size.

The fuzziness of the WIP8 icons is not due subpixel sampling. Its just Mcneel’s lame attempt to avoid aliasing effects because they don’t know how to do the resampling correctly. What it sounds like Mcneel may be doing is converting the vector info to one bitmap size and then converting that bitmap to the other sizes that users request. So there may be more than one resampling process involved, neither of which is being done well.

Of course, doing the icon size resampling correctly is likely to take more time. But it seems to me that most users set the size of their icons then leave it alone. If it takes a few seconds longer for a one time operation that’s no big deal.

On computers

… is one of the first thing that was optimized in past exactly to avoid blurring and to squeeze the most from low resolution monitors.

It might look trivial today, but it’s not. It was not easy.

It’s a W.I.P.
Other users have reported and are reporting this problems.
The whole UI engine was rebuilt to have Win and Mac version share the same perks (and defects, for now) … let’s be confident they’ll try to give us sharp icons for the release.

6 Likes

But isn’t this kinda adapting and aligning? Also I have always thought that text has it’s own special rendering pipeline on any computer system. This is the very reason why same fonts look different win vs. mac, because they have complete different philosophies on how text should look like.

When I have worked with vector graphics and UIs, I have have always seen a clear difference in sharpness of things that are on the pixel grid vs. stuff that is not. And this is especially true with the small stuff like icons and buttons.

mac and win use different font systems. So what?

If you are still trying to claim its impossible to convert vector data to clear raster data without it being blurry, you don’t know what you are talking about.

I’m guessing that the problem may be that McNeel decided to make the icon size responsive to a slider so that all the icons have to change in real time as the user moves the slider. The algorithm for making good icon image may not be able to keep up and so Mcneel decided to use a faster algorithm that can keep up but also significantly degrades the image quality. There is nothing wrong with doing that, but to leave the user with the degraded images after users have picked the size they want and hit the OK button is inexcusable and lazy.

My point was that text has its own rendering pipeline which is different from how SVG’s are rasterized and anti-aliased.

All I referring is this kind of workflow when designing icons or graphics:

@milezee I had the same problem, and then figured out if u go into the options for the toolbar button size (EDITED), you may have it set to an odd number (eg. 15) — make it an even number, and they should look right.

1 Like

I’ll give that a try Monday when back on PC, thanks Alan

1 Like

On my MBP 16" 2019 Intel machine, the icons are better, still not quite as sharp as V7 on my Mac, but much better than on works Windows PC. Hopefully the clever McNeelies can fine tune these visual UI problems, screenshot attached from 16" MBP, happy weekend all