Library: add overview column

[ronso0]

This is based on @ninomp's initial POC commit 9932cfc
https://github.com/ninomp/mixxx/tree/overviewsinlibrary

I removed the disabled parts and added some TODOs/concerns.
(I'll split up some of the commits so it's a bit easier to review)

• all overview renderers are now in src/waveform/overviews, i.e. WOverView and OverviewDelegate use the same renderer
  (I adopted the RGB simplifications made by @Nino MP, and simplified the others, too)
• the renderer selected for the decks is also used in the library (incl. live update when changing it in the preferences)

Peforms nicely, though I bet some parts can be optimized.
For example, why pass a mixxx::DbConnectionPoolPtr to static FutureResult OverviewCache::prepareOverview to create a AnyalysisDAO for each request, and not a AnyalysisDAO pointer (probably in TrackCollection)?

[ninomp]

For example, why pass a mixxx::DbConnectionPoolPtr to static FutureResult OverviewCache::prepareOverview to create a AnyalysisDAO for each request, and not a AnyalysisDAO pointer (probably in TrackCollection)?

IIUC Each thread needs its own database connection, we cannot share/reuse them. Actually, I'm currently experimenting with using a dedicated thread to render overviews. I'll comment back when I get it working.

[ywwg]

I will def review this when you think it's ready for a look

[ronso0]

I will def review this when you think it's ready for a look

In case you refer to this PR (thanks!), I think it's better to wait for @ninomp's update.
I did this primarily to get it working for myself so I can test it in my live builds. (should probably add some VERIFY_OR_DEBUG_ASSERT here and there, just in case.. 😆 )

[Swiftb0y]

I'm afraid this needs a bunch of work before I trust it...

[Swiftb0y]

why is this needed here but not in slotOverviewChanged?

[Swiftb0y]

remove completely, right?

[Swiftb0y]

using a string as a cache key is not particularly efficient. a struct with a qHash implementation would be better.

[ronso0]

(I think most of this is adopted from CoverArtCache)

[ronso0]

What about this?
https://doc.qt.io/qt-6/qpixmapcache-key.html#details

Use QPixmapCache::insert() to receive an instance of Key generated by the pixmap cache. You can store the key in your own objects for a very efficient one-to-one object-to-pixmap mapping.

Does such a one-to-one map QString <--> Key map/hash make sense performance wise?

[Swiftb0y]

Probably not, you're right. I didn't see that this was using QPixmapCache internally. The only improvement then is

Suggested change

	QString pixmapCacheKey(TrackId trackId, QSize size, WOverview::Type type) {
	return QString("Overview_%1_%2_%3_%4")
	.arg(static_cast<int>(type))
	.arg(trackId.toString())
	.arg(size.width())
	.arg(size.height());
	}
	QString pixmapCacheKey(TrackId trackId, QSize size, WOverview::Type type) {
	return QStringLiteral("Overview_%1_%2_%3_%4")
	.arg(static_cast<int>(type),
	trackId.toString(),
	size.width(),
	size.height());
	}

[Swiftb0y]

Suggested change

	inline QImage resizeImageSize(const QImage& image, QSize size) {
	QImage resizeImageSize(const QImage& image, QSize size) {

[Swiftb0y]

this doesn't have internal state, nor does it need to be a singleton. Consider making this free functions instead and removing the static data. Pass it instead when calling the functions.

[ronso0]

@Swiftb0y Thanks for your review, but I'm not inclined to fixup mayself since @ninomp said they would / are about to rework this anyway.

@ninomp Please share your progress early, even if it's rough and dirty.
Thanks!

[ronso0]

FYI I'll keep pushing fixups to hopefully make this safer and maybe a bit faster for my own builds.

[ninomp]

I just created a PR that contains the work I've done in the past week or so: #13644