Graphics.DrawPicture anti-aliasing under Cocoa

yes of course one can use RGBSurface.Pixel to emulate the correct behavior, but I suspect the redraw would be unusably slow. So thanks for offering, but don’t waste your time trying. I will likely have to do this in C and always draw a 1x picture in xojo, with scale up/down done manually because of this issue.

Thats what I use that code for.
I dont resize in the paint event, I resize once to an offscreen picture and then draw picture that in the paint.
Its fast enough, but your needs may dictate a constant resizing process, I wouldn’t know.

The method is here if anyone else can use it, and FWIW, I agree with you… this shouldn’t be needed.
I find it difficult to imagine a situation where someone would actually want to write a program that needed the antialiasing to happen.

A photo or image editor needs to see the actual pixels, for example.

I just quickly put together a 12 lines program that picks color with RGBSurface then FillRect over a new picture and it displays instantly.

[quote=123869:@Jeff Tullin]I find it difficult to imagine a situation where someone would actually want to write a program that needed the antialiasing to happen.
[/quote]

The layman who enlarges a photo will probably not like seeing big pixels, and may prefer a smoother rendition. For size reduction, the thread https://forum.xojo.com/9403-scale-quality-of-canvas-control had some pretty compelling examples in favor of antialiasing.

That said, I concur : antialising should be made optional. Or, in an ideal world, the kind of extrapolation should be a choice like in Photoshop.

How many rects did you draw? For a 2560 x 1440 display and my image filling the screen @ zoom 200% you’d need to draw ? 2560 x 1440 / 4 = 921600 rects. Is that really fast? If so, maybe I should give RGBsurface more credit then.

I based my test on a smaller picture, the size of the red samples you attached to the bug report.

that was just a very small subregion for illustration purposes, I suspect drawing entire screen-full would be too slow. Regardless, XOJO needs to correct this problem.

Never said otherwise. In the meantime, you need a workaround, and Objective-C is probably the way to go.