Skip to content

Conversation

@hebasto
Copy link
Member

@hebasto hebasto commented Aug 22, 2020

This PR adds SVG support, and replaces bitcoin.png with bitcoin.svg.
Here are the benefits:

Fedora 32:
Screenshot from 2020-08-22 19-44-45

Ubuntu Focal 20.04:
DeepinScreenshot_select-area_20200822224245

"About Bitcoin Core" dialog with this PR:
Screenshot from 2020-08-22 22-47-19


bitcoin-core/packaging#27 (comment):

I slighly remember that the png I made where slighly different then the SVG (optimized shadows, etc.). But not sure if this is still the case and if it matters. Just something to dbl-check.

With Qt 5.9.8 (our gitian builds) difference in shadows is observed. No differences with newer Qt versions.

@maflcko
Copy link
Member

maflcko commented Aug 22, 2020

I slighly remember that the png I made where slighly different then the SVG (optimized shadows, etc.). But not sure if this is still the case and if it matters. Just something to dbl-check.

Source: bitcoin-core/packaging#27 (comment)

@luke-jr
Copy link
Member

luke-jr commented Aug 22, 2020

Isn't SVG rendering a lot of complexity to add? What's the benefit?

If we want to use SVGs in the source code, we could adopt Knots's build system changes that render SVG to PNG at dist-time.

@hebasto hebasto marked this pull request as ready for review August 22, 2020 20:03
@hebasto
Copy link
Member Author

hebasto commented Aug 22, 2020

@luke-jr

Isn't SVG rendering a lot of complexity to add?

How does SVG rendering complexity differ from QIcon complexity with multiple pixmaps, icon engines and rescaling?

What's the benefit?

Unconditional visual quality.

@hebasto
Copy link
Member Author

hebasto commented Aug 22, 2020

@jonasschnelli

As you're a designer of bitcoin.svg, mind looking at this PR? 🌴

@luke-jr
Copy link
Member

luke-jr commented Aug 22, 2020

How does SVG rendering complexity differ from QIcon complexity with multiple pixmaps, icon engines and rescaling?

Choosing an image is absolutely trivial in comparison to rendering a vector image...

Why would we ever be rescaling?

What's the benefit?

Unconditional visual quality.

You get the same quality no matter what stage you render.

@hebasto
Copy link
Member Author

hebasto commented Aug 22, 2020

Choosing an image is absolutely trivial in comparison to rendering a vector image...

Isn't rendering a vector image hidden by qtsvg for us?

Why would we ever be rescaling?

In cases when a requested pixmap size does not coincide with one of stored by QIcon.

You get the same quality no matter what stage you render.

The difference in quality is obvious on screenshots though.

@DrahtBot
Copy link
Contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@luke-jr
Copy link
Member

luke-jr commented Aug 22, 2020

Isn't rendering a vector image hidden by qtsvg for us?

Yes, the concern is importing something complex like qtsvg into the overall codebase/runtime process... Any vulnerability compromises the entire program.

I cases when a requested pixmap size does not coincide with one of stored by QIcon.

I don't know of any cases where that should happen.

The difference in quality is obvious on screenshots though.

Most of the screenshots here are the DE, not Bitcoin Core...? Providing SVGs for that purpose seems fine and aside from using SVGs inside Core itself.

If we're getting scaling artefacts inside Core, we obviously aren't rendering to the size we're using. That's fixed by adjusting what sizes we render.

@practicalswift
Copy link
Contributor

Is the GUI repo the appropriate home for a PR like this? :)

@hebasto
Copy link
Member Author

hebasto commented Aug 23, 2020

@luke-jr

Most of the screenshots here are the DE, not Bitcoin Core...? Providing SVGs for that purpose seems fine and aside from using SVGs inside Core itself.

Correct. bitcoin-core/gui#38 or #15068 should be used instead.

@practicalswift

Is the GUI repo the appropriate home for a PR like this? :)

https://github.com/bitcoin-core/gui is for changes within src/qt only. But this PR touches build-aux/m4/bitcoin_qt.m4, depends/packages/qt.mk, and src/Makefile.qt.include.

Closing.

@hebasto hebasto closed this Aug 23, 2020
@NicolasDorier
Copy link
Contributor

Given SVG files are auditable (it's only text), and we don't accept SVG from any untrusted source, I don't think this is a good concern @luke-jr

@maflcko
Copy link
Member

maflcko commented Aug 26, 2020

Concept ACK if this worked out of the box without the build system changes.

@hebasto
Copy link
Member Author

hebasto commented Aug 26, 2020

Concept ACK if this worked out of the box without the build system changes.

The build system changes are required for static builds.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[RFC] qt: Icon scaling issue on some Linux desktop environments

6 participants