Fixed ability to use all the drawing modes

[skibu]

Turns out that BLEND_MODES was missing ['SATURATE'] = 3 which was preventing one from using that draw mode and any of the draw modes after that one. Quite limiting! I'm certain this was just a typo.

Since added a BLEND_MODE also had to fix screen_set_operator().

[tlubke]

(#1247 (comment)) Based on this, I think the index limit and omission of the SATURATE mode were purposeful at the time.

Here's all of the reasoning that I can remember.

• ADD output is identical to SATURATE (I can't remember if this is because of being grayscale).
• DEST_ATOP should be identical to OVER (which is the default operator mode).
• HSL_HUE, HSL_SATURATION, HSL_COLOR, and HSL_LUMINOSITY don't provide much value in grayscale.

---

Since screen.set_operator() can take either a string or a number, changing the index order could break existing scripts that might use it with an index directly.

---

Having said all that, the range-check change in screen.c looks correct, and it may be worth considering removing the limit for the purpose of interacting with non-grayscale colorspaces through mods.

[skibu]

Ah, SATURATE duplicating the functionality of ADD explains why it was removed in screen.lua . But there is still a definite bug that causes the operators beyond ADD to not work correctly because the indexes are off by one (even if one uses the name of the operator instead of the number). I tried both using the index and the name of the operator and I got incredibly confusing results since the wrong operator was being used.

The root of the problem is a mismatch between the operator list in screen.lua and in screen.c .

In screen.c the list of operators is:

static cairo_operator_t ops[NUM_OPS] = {
    CAIRO_OPERATOR_OVER,
    CAIRO_OPERATOR_XOR,
    CAIRO_OPERATOR_ADD,
    CAIRO_OPERATOR_SATURATE,
    CAIRO_OPERATOR_MULTIPLY,
    CAIRO_OPERATOR_SCREEN,
   ...

If SATURATE should indeed not exist (will need you to confirm this) then proper solution would be to also update the operator list in screen.c so it matches the list in screen.lua .

[tlubke]

Ah, I see the issue now. Yes, I think the indices in screen.lua are the intended ones, and screen.c was not updated appropriately. It doesn't look this was a regression either (I'm surprised it took nearly 5 years for the issue to be detected!).