So BitmapForCaching is not exactly the answer. It’s close though. For a 2x scale, I get back an 80x80@144 picture. That’s not unusual, but it’s not ready to use as-is. It essentially creates the same thing I was creating inside the loop in my original code, just a bit simpler. I still have to pack it into a multi-res picture. So my code looks like:
Dim Temp As Picture = Self.Window.BitmapForCaching(40, 40)
Temp.Graphics.DrawPicture(Shadow, 0, 0)
Temp.Graphics.DrawPicture(Background, 0, 0)
Temp.Graphics.DrawPicture(Foreground, 0, 0)
Dim Composite As New Picture(40, 40, Array(Temp))
The trick I learned is that I don’t need a full set of pictures to assemble a multi-res picture from. So this saves some work, but still feels like a silly workaround.
[quote=364003:@Norman Palardy]if this is in the paint event you only need one image at whatever scale factor etc that the graphics object already has
one paint event wont require more than one resolution[/quote]
Yeah, but it feels wrong to need to create a picture just to create another picture. In my code above, why can’t I just say that Temp is a 2x picture?
I mean, I know the technical reason. You can’t offer a Picture(WidthInPoints As Integer, HeightInPoints As Integer, Scale As Double) constructor because it would collide with the “normal” constructor. But why not a similar shared method? Picture.CreateAtScale or something like that?
[quote=364010:@Norman Palardy]grab the extensions from http://documentation.xojo.com/index.php/Window.BitmapForCaching
use g.BitMapForCaching and its all set up with the right size scale etc etc etc[/quote]
But that’s what I’m getting at. That “works” but still requires the step of packing into a second picture object. BitmapForCaching or creating it yourself both end up creating a 80x80@144 picture, when I really need one that reads as 40x40 so that it draws correctly to the graphics context. So far, the only way I’ve found to make that happen is to create an oversized picture using BitmapForCaching or “manually”, then to pack it into a second picture object as in the code I posted above. Packing it into a second picture is the part that feels wrong and unintuitive.
I’d would appreciate if in the Example Projects folders (inside Xojo folder) there were a few examples showing how to deal with situations like the present one or even more complex ones. Webseminars are good, but I sometime prefer learning and experimenting on physical files.
This way the picture will always draw at the correct size, regardless of what viewScale is or whatever the pixel dimensions were used to create myGreatPicture. On the Mac, I seem to recall that Apple will now cache it at that size for repeated drawing.
Since HIDPI Apple have suggested that when drawing images to use the rect functions as opposed to the point functions, I guess for this exact reason. With NSImage you can specify the draw size, or alter it at any time. This is most helpful when adding icons to interface elements.
This way the picture will always draw at the correct size, regardless of what viewScale is or whatever the pixel dimensions were used to create myGreatPicture. On the Mac, I seem to recall that Apple will now cache it at that size for repeated drawing.
Since HIDPI Apple have suggested that when drawing images to use the rect functions as opposed to the point functions, I guess for this exact reason. With NSImage you can specify the draw size, or alter it at any time. This is most helpful when adding icons to interface elements.[/quote]
Yeah. In my particular case, the composite is then sliced and stretched, so I’m already using those parameters to do that. It would be a maddening exercise to handle both the slicing and scaling at the same time.