"I told you DIB drawing functions would likely not "stick" on B+ canvas. :c)"
Yes, and I'd already figured that out myself, and that has nothing to do with having to repaint all bitmaps when drawing with windows GDI functions in a C program. :-)
Apparently the reason GDI functions don't "stick" on a canvas is because the GDI functions draw to the canvas's "front buffer", and when the canvas flips, the unmodified backbuffer overwrites it.
But what I realise now (I think), is that this "canvas" gadget is really just a couple device independent bitmaps, and Blitz is calling scaleblt every time Windows sends Blitz a WM_PAINT message. (Or I call FlipCanvas)
That is what I wish I'd known three days ago.
Because that means there is no gadget in windows that will behave like a canvas. And finding that was integral to my plan.
In order for me to simulate a canvas, I would have to be able to intercept the WM_PAINT messages before Blitz gets them, and call the GDI functions to redraw my bitmap into the Window. But I can't do that. So all my efforts have been for naught.
"Why not just limited the zooming options to something like 100%, 200%, 75% and 50%? Shouldn't take ages to produce the four pics?"
Actually, I have done something like that:
http://www.blitzbasic.com/codearcs/codearcs.php?code=1301
That is 8x faster than the standard scaleimage command. But a size like 75% is not possible with this method. It can do 25%, 33%, 50%, 100%, 200%, 300%, but not 75% or 150%.
Ie, it can draw one line for every three, (33%) or it can draw three lines for every one (300%) but it can't do anything in between, because that would be just as slow as ScaleImage with TFormFilter set to False.
But you're mistaken about it not taking ages to produce four pics. 200% is the max I'm going to allow, because it takes a good two seconds to scale an image from 1024x1024 to 2048x2048, and my program will often be dealing with images that are 2048x2048... So it will take eight seconds to soom in to 200%, and two more to scale down to 1024x1024. As such, it is not an option to preclauclate all the scales for each window as that would take too long and the images will be modified too often.
I wonder though... Would the rect command be faster than drawing four pixels in a square manually. Hm...
Also, would the command to copy a block of pixels be faster than reading them individually. If I am scaling an image up, I could use (HEIGHT*WIDTH) copyrect commands to copy the image. More pixels would have to be read and written, but it's possible the command would still be faster if it uses the GDI commands to do the copy.
Unfortunately, doing the same trick to scale down is harder, and may not be worthwhile.
Yes, and I'd already figured that out myself, and that has nothing to do with having to repaint all bitmaps when drawing with windows GDI functions in a C program. :-)
Apparently the reason GDI functions don't "stick" on a canvas is because the GDI functions draw to the canvas's "front buffer", and when the canvas flips, the unmodified backbuffer overwrites it.
But what I realise now (I think), is that this "canvas" gadget is really just a couple device independent bitmaps, and Blitz is calling scaleblt every time Windows sends Blitz a WM_PAINT message. (Or I call FlipCanvas)
That is what I wish I'd known three days ago.
Because that means there is no gadget in windows that will behave like a canvas. And finding that was integral to my plan.
In order for me to simulate a canvas, I would have to be able to intercept the WM_PAINT messages before Blitz gets them, and call the GDI functions to redraw my bitmap into the Window. But I can't do that. So all my efforts have been for naught.
"Why not just limited the zooming options to something like 100%, 200%, 75% and 50%? Shouldn't take ages to produce the four pics?"
Actually, I have done something like that:
http://www.blitzbasic.com/codearcs/codearcs.php?code=1301
That is 8x faster than the standard scaleimage command. But a size like 75% is not possible with this method. It can do 25%, 33%, 50%, 100%, 200%, 300%, but not 75% or 150%.
Ie, it can draw one line for every three, (33%) or it can draw three lines for every one (300%) but it can't do anything in between, because that would be just as slow as ScaleImage with TFormFilter set to False.
But you're mistaken about it not taking ages to produce four pics. 200% is the max I'm going to allow, because it takes a good two seconds to scale an image from 1024x1024 to 2048x2048, and my program will often be dealing with images that are 2048x2048... So it will take eight seconds to soom in to 200%, and two more to scale down to 1024x1024. As such, it is not an option to preclauclate all the scales for each window as that would take too long and the images will be modified too often.
I wonder though... Would the rect command be faster than drawing four pixels in a square manually. Hm...
Also, would the command to copy a block of pixels be faster than reading them individually. If I am scaling an image up, I could use (HEIGHT*WIDTH) copyrect commands to copy the image. More pixels would have to be read and written, but it's possible the command would still be faster if it uses the GDI commands to do the copy.
Unfortunately, doing the same trick to scale down is harder, and may not be worthwhile.