Image blending modes bis


#1

hi,

Since you’ve recently refactored the way the LowLevelGraphicContext works, I was wondering if it was now a better time for considering adding Image blending modes to the Graphics class?

cf http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=2429


#2

It would indeed be a good time, and I thought about doing it - but it’d take at least a couple of hard days work, and I couldn’t face it. Not forgotton, but on the back-burner.

TBH if I’d ever thought of a situation where any of these modes were useful, I’d probably have done it long ago. What is it that you need it for?


#3

The need for that comes very often when working with our graphic designer which uses plenty of screen, multiply…etc blending modes

There are simple cases were we can just render the graphics as an Image and load it from resources but each time we need the UI to be resizable we have to draw the graphics algorithmically.
In thoses cases we end up cheating with transparency, flattened gradients… but that’s just a crude approximation of the original artwork.

If you want some more interresting uses you can also have a look in QT’s demo examples IIRC.


#4

Fair enough. It’s not that it’s very hard to add, just a lot of typing and testing!


#5

That’s why I took the time to write and test all those PixelBlenders classes in my previous post.
I hope you’ll have the time to make something out of it.


#6

yes please, it is something i look forward since ages.

we deserve such kind of operations in the juce graphics classes, with this we don’t need anything else !


#7

The thing that bothers me is that if there are, say, 16 modes, I don’t want the graphics code to bloat to 16x its current size by templating all the high level graphics operations with a rendering mode!

But I also can’t write code that has a switch statement to choose the right blending function every time it draws a pixel… And to write something in between would be extremely tricky…


#8

Surely just a plugin model ala the LAF class. Presumably a graphics context will not be switching blending mode durning a draw, so if Graphics::setBlending() took a Blend sub-class instance then no switch would be needed. The amount of templated bloat would then be up to the app writer. If they need it, then they pay the price.

(I haven’t actually looked at any of the new codebase as I’m stuck on 1.46 until I nail the last few features holding up an official v1 of my app, so this may all be hopelessly naive).


#9

Well, that wouldn’t really work - what I’d want to do is to just make it a function of the low level graphics context to set the blend mode, so that for the CoreGraphics context, I’d just call the native set blend mode function.

I think I’d have to come up with some sort of two-level approach where normal blending is done via a fast template, and other modes are done via a virtual class that handles painting rows of pixels, so the extra overhead would only be a virtual method call per pixel row. All a total PITA to write though! Volunteers welcome!


#10