Yet another enhancement for CustomFilterCallback

[Seymour Clufley]

As it is, this drawing mode works very slowly because the callback procedure is called for every pixel.

A way round this would be some flags to specify when to call the callback procedure.

Code: Select all

#CFC_AlwaysCall ; as it is just now
#CFC_ForNewTopColours ; if the top colour has been drawn already, use the value the proc returned for it. Otherwise it's a new top colour, so call procedure.
#CFC_ForNewBottomColours ; if the bottom colour has been drawn already, use the value the proc returned for it. Otherwise it's a new bottom colour, so call procedure.
#CFC_ForUniqueCombinations ; if the combination of the top colour and the bottom has been drawn already, use the value the proc returned for it. Otherwise it's a new combination of top colour and bottom colour, so call procedure.

I think this would drastically reduce the calls to the callback, making many drawing operations much faster.

A simpler way would be just to have another mode: #PB_2DDrawing_QuickCustomFilter. This would do away with the x and y parameters (the callback procedure would be Procedure.i MyPaint(top.i,bottom.i)). But the system described above would be more flexible.

[Thorium]

If speed madders, why not using DrawingBuffer and draw directly without any callback?
Well you have to take care about the pixel format on direct drawing but it's the fastest way to do it. Or did i miss something?

[Seymour Clufley]

Because then we would lose the benefits and ease of using PB's drawing functions, especially DrawText.

[freak]

This would be slower than it is right now because the functions would need to track all color combinations that were already drawn which would be dead slow.

[Seymour Clufley]

Not if the number of colours involved is a small number. And it would be, otherwise you just wouldn't use a system like this.

The thoroughness of calculating for every pixel is good for images with a wide colour range, but bad for images with a narrow colour range.

The proposed "shortcut" of calculating only for new colours would be dead slow for images with a wide colour range, but very fast for images with narrow colour range.

What I mean is: yes, the system would have to track all colour combinations, but a sane programmer would only use it if there weren't going to be many colour combinations.

[Seymour Clufley]

Or you could just place an arbitrary limit of the number of colours to store in memory. Leave it up to the programmer, and he could decide what is an appropriate "memory range" for the images he's working with.