prevent invalid cairo matrix in expose

[dterrahe]

prevent cairo errors reported up the chain after darkroom expose

(darktable:21578): Gtk-WARNING **: 10:11:12.748: drawing failure for widget 'GtkDrawingArea': invalid matrix (not invertible)

(darktable:21578): Gtk-WARNING **: 10:11:12.748: drawing failure for widget 'GtkBox': invalid matrix (not invertible)

(darktable:21578): Gtk-WARNING **: 10:11:12.748: drawing failure for widget 'GtkOverlay': invalid matrix (not invertible)

(darktable:21578): Gtk-WARNING **: 10:11:12.748: drawing failure for widget 'GtkGrid': invalid matrix (not invertible)

(darktable:21578): Gtk-WARNING **: 10:11:12.748: drawing failure for widget 'GtkBox': invalid matrix (not invertible)

(darktable:21578): Gtk-WARNING **: 10:11:12.748: drawing failure for widget 'GtkGrid': invalid matrix (not invertible)

(darktable:21578): Gtk-WARNING **: 10:11:12.748: drawing failure for widget 'GtkBox': invalid matrix (not invertible)

(darktable:21578): Gtk-WARNING **: 10:11:12.748: drawing failure for widget 'GtkWindow': invalid matrix (not invertible)

as reported here #18375 (comment)

Since we no longer throw away the cairo context when returning from expose (we used to copy into an extra intermediary buffer) these error conditions now persist.

@ralfbrown since you looked at this recently, do these make sense to you?

[TurboGit]

Is that standard C? First time I see such construct? An empty section for ? means what? Return the zoom_scale here?

EDIT: Anyway, I think this should be avoided and we should be explicit.

[dterrahe]

https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html

[da-phil]

Is that standard C?

At least not ISO C before C2X

I don't understand the necessity of this check, line 575 already makes sure zoom_level will be non-zero.
So, you assume that full.pipe->processed_width can be zero under some circumstances?

[dterrahe]

So, you assume that full.pipe->processed_width can be zero under some circumstances?

No, I'm not assuming.

preview_pipe and full.pipe get processed in separate threads so there are "race" conditions where one is set and the other isn't. That occasionally leads to a zero zoom_scale and a divide by zero in the code that uses it. This used to go unnoticed because we created and threw away an intermediate cairo surface. But it gets flagged by gtk now.

I specifically asked for feedback from @ralfbrown since he made further changes touching this code since I last did any significant restructuring.