PureBasic Forums - English

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.
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.

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?

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

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.

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.

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.