You must have been using auto-complete on Windows...
StretchBlit() isn't official public API, it's only meant to be used
internally. Use Blit() instead, or better yet, don't create a
wxMemoryDC, and just use DrawBitmap() directly while setting the user
scale as needed, or just resizing the bitmap before-hand.
Regards,
Bryan Petty
Nevermind, I was looking at 2.8 API. Apparently it is new in 2.9.
Anyway, the workarounds mentioned should still work though.
What is the error you're getting?
Regards,
Bryan Petty
Actually, a 500x500 32-bit image blown up 3200% is closer to 1GB.
But this is typically where you would actually grab the sub-bitmap
consisting of just what part of the image is actually going to be
shown on screen, and blowing that up, which will only take closer to
3-6MB typically, depending on the size of the window. You don't need
to blow up the entire image.
You are right though, this is still not nearly as efficient as it
could be (but it is a lot more efficient than you think it is if done
right).
Anyway, I've now tested all approaches mentioned in this thread on
both wxOSX/Carbon and wxOSX/Cocoa. Not only does it not work with
StretchBlit() on either Carbon or Cocoa, but it also doesn't work with
Blit() if you change the user scale (it does however work if you don't
change the user scale, but that's not going to help you unless you
want to resize the bitmap first).
What did work on both Carbon and Cocoa though was my initial
suggestion of setting the user scale, and using DrawBitmap(). Note
that this does not involve a single call to resize the bitmap/image.
You simply grab the sub-bitmap (for efficiency) set the user scale
appropriately, and call DrawBitmap() with your sub-bitmap.
It may still be possible to fix whatever the issue is with
StretchBlit()/Blit()/wxMemoryDC on Mac. It would at least be worth
opening a ticket on the wxWidgets tracker anyway.
Regards,
Bryan Petty