darkroom: reduce filtering sooner for when zoomed in

[dtorop]

In debugging what @MStraeten noticed in #9835 (comment)

unfortunately moving the live-picker results in a reprocessing of the preview image each time the picker is set, so it comes with a price - depending on the used hardware and the pixelpipe this can be very time consuming (a 'working...' on picking a color for setting a parametric mask is annoying)

it seems that the darkroom center view should fall back to fast filtering sooner than it current does.

Currently CAIRO_FILTER_FAST is enabled at > 100% scale for lodpi screens and at > 400% (e.g. 800%) scale for hidpi screens. This makes updates at 400% on hidpi particularly slow.

This PR enables CAIRO_FILTER_FAST at >= 100% for lodpi and at >= 200% for hidpi. This noticeably speeds up center view refreshes at 400% for hidpi.

This PR also uses fewer function calls/mutexes as it takes advantage of the caller already knowing the current closeup value, and that being enough to determine when to go to lower resolution.

Note that CAIRO_FILTER_FAST appears to be capable of deciding to use no scaling at 1:1. See https://github.com/freedesktop/cairo/blob/923715f2e9acec31f6af406f39e14c36f9f7365c/src/cairo-pattern.c#L3424-L3436.

This PR fixes a bug by which the second window reduced filtering depending on the zoom of the primary window.

[dtorop]

This fix should be fixed now. I updated to PR comment as well, and merged the multiple commits down to one with a (finally, I think) correct commit message.

Essence:

• Behavior should be unchanged for lodpi
• Should be fixed for hidpi
• Should be fixed for 2nd window

[TurboGit]

I'm still not sure about this. The gui->ppd is controlling the down-sampling so it seems correct to control the behavior based on this here no? See option down-sampling in the prefs which can be original, 1/2, 1/3 or 1/4.

[dtorop]

gui->ppd is already controlling the closeup value, which controls the dt_dev_get_zoom_scale() result above... So ppd is currently double-applied: once in setting up closeup, and once in _get_filtering_level(). For a ppd of 1 (lodpi), that is fine (a NOP). For a ppd of 2, though, fast filtering kicks in one notch more (800%) than what extant code wants.

Also, the > 1.0 should be >= 1.0 (or equivalent with epsilon). For 1:1, Cairo does the right thing, regardless of the current filter, but above that things go awry, which is why hidpi fast filtering is currently is OK at 200%, slow at 400%, and OK at >= 800%.

Example code which already sets closeup based on ppd:

darktable/src/views/darkroom.c

Lines 3674 to 3698 in 52f261b

	// for 200% zoom or more we want pixel doubling instead of interpolation
	if(scale > 15.9999f / ppd)
	{
	scale = dt_dev_get_zoom_scale(dev, DT_ZOOM_1, 1.0, 0);
	zoom = DT_ZOOM_1;
	closeup = low_ppd ? 4 : 3;
	}
	else if(scale > 7.9999f / ppd)
	{
	scale = dt_dev_get_zoom_scale(dev, DT_ZOOM_1, 1.0, 0);
	zoom = DT_ZOOM_1;
	closeup = low_ppd ? 3 : 2;
	}
	else if(scale > 3.9999f / ppd)
	{
	scale = dt_dev_get_zoom_scale(dev, DT_ZOOM_1, 1.0, 0);
	zoom = DT_ZOOM_1;
	closeup = low_ppd ? 2 : 1;
	}
	else if(scale > 1.9999f / ppd)
	{
	scale = dt_dev_get_zoom_scale(dev, DT_ZOOM_1, 1.0, 0);
	zoom = DT_ZOOM_1;
	if(low_ppd) closeup = 1;
	}

[TurboGit]

Ok, thanks for clarifying. So this sounds good now. I'll merge right away to ensure lot of field testing as this is a really delicate area and I'm not sure to have a complete view on the possible consequences.

[TurboGit]

Thanks !