FYI: a MBPr does not switch to the Geforce GPU. It uses the Intel Iris Pro. My guess it only uses there Geforce when you are playing games etc…
There are many intense calculations being performed 
a 2-dimensional canvas (X,Y) is being manipulated as if it were a 3-dimensional space (X,Y,Z)…the calculations become 16 times (literally) as many when alignments are enabled.
So, using the same formula devised to judge the canvas; only including more detail…if the same canvas is used with the same number of calculations on a non-retina mac, and the speed is noticeably greater (the same as Windows/Linux) than that of a retina mac…then the problem lies in retina rendering, yes?..Where does graphics rendering happen (not the monitor :-p)
Windows - Same Canvas - Same Calculations/Setup - Great Performance
Linux - Same Canvas - Same Calculations/Setup - Great Performance
Mac (Non-Retina) - Same Canvas - Same Calculations/Setup - Great Performance
Mac (Retina) - Same Canvas - Same Calculations/Setup - Horrible Performance
The human eye sees between 24-33 FPS…here’s the most recent average retina benchmarks… (not saying retina is bad, but Windows, Linux, and non-retina macs fps averages 45-60 FPS…vs. retina’s 31 and under FPS)
Has anyone noticed any change in performance with OS X 10.9.3? It changed the amount allocated to VRAM. http://www.macrumors.com/2014/05/20/10-9-3-maximum-vram-increase/
I found a way to speedup the Canvas paint event A LOT ! In my experience this multiplies with at least 3 times the drawing speed.
Put this in the paint event (all credits to Sam for this !!)
declare sub CGContextSaveGState lib “Cocoa” ( context as integer )
declare sub CGContextSetInterpolationQuality lib “Cocoa” ( context as integer, quality as integer )
declare Sub CGContextRestoreGState lib “Cocoa” ( context as integer )
Dim CGContextRef as integer = g.handle( g.HandleTypeCGContextRef )
CGContextSaveGState CGContextRef
CGContextSetInterpolationQuality CGContextRef, 1
// ---------------------- Do drawing stuff here
// ---------------------- Finished, then restore the previous state.
CGContextRestoreGState CGContextRef
Did some more test with CGContextSetInterpolationQuality
In all cases it speeds up the paint event of the canvas tremendously !!
May I dare to say it is now ‘fast’ enough for Retina? 
Huge thanks to SamR for this great declare !
[quote=91137:@Christoph De Vocht]Did some more test with CGContextSetInterpolationQuality
In all cases it speeds up the paint event of the canvas tremendously !!
May I dare to say it is now ‘fast’ enough for Retina?
Huge thanks to SamR for this great declare ![/quote]
If you’re willing, I’d be glad to introduce this declare in the 1.6 beta test-run if you’re willing to do a little testing 
[quote=91209:@Matthew Combatti]If you’re willing, I’d be glad to introduce this declare in the 1.6 beta test-run if you’re willing to do a little testing
[/quote]
Sure thing.
[quote=91052:@Christoph De Vocht]declare sub CGContextSaveGState lib “Cocoa” ( context as integer )
declare sub CGContextSetInterpolationQuality lib “Cocoa” ( context as integer, quality as integer )
declare Sub CGContextRestoreGState lib “Cocoa” ( context as integer )
Dim CGContextRef as integer = g.handle( g.HandleTypeCGContextRef )
CGContextSaveGState CGContextRef
CGContextSetInterpolationQuality CGContextRef, 1
// ---------------------- Do drawing stuff here
// ---------------------- Finished, then restore the previous state.
CGContextRestoreGState CGContext[/quote]
Is there any downside to using this? If not why is this not part of the Xojo framework?
What if one uses it with a graphics object from a clipped region? What if one creates a clipped graphics object on a graphics object AFTER one has done this to it?
What about a with the graphics object from a picture?
- Karen
[quote=91446:@Karen Atkocius]Is there any downside to using this? If not why is this not part of the Xojo framework?
[/quote]
See Erics reply in https://forum.xojo.com/12286-speeding-up-cocoa-drawing
In a screenshot from a beta tester it would appear that more than canvas is not functioning properly using retina display. Other xojo controls not displaying or working properly appear to be:
Containercontrol
Vertical scrollbar
Labels
Pushbuttons
These are xojo “native controls.” I myself do not use retina display but it would appear the Xojo Framework is not functioning properly using retina by your screenshot, or some after compile plist retina tags were not added to make the application “retina friendly.” Oddly, the color picker bars and top rulers appear, and were created using the SimDesignerCanvas as well. This may be something Norman could she’d some light on as no one else has stated retina display bugs this large and detrimental except for listboxes in their own retina applications. Oddly the window title is 8217 as well?
The other advice I have for you, without looking at the code is to make that you’re only updating what you need. Use invalidate and pass in the smallest rectangle you can.
invalidate( left, top, width, height)When drawing images, try to avoid scaling the image, you can always cache the image at a certain size.
Make sure that you don’t use DoubleBuffer on the Mac OS, as the OS already double buffers windows, however there is an option to disable this (although I wouldn’t recommend it, unless you want your windows to flicker and tear). The double Buffering is what keeps the Mac interface looking so slick and reduces flickering/tearing, Windows doesn’t have this, which is why games in Windows are generally faster, but then you have to employ hacks to make your interface stable.
Don’t forget that a Retina MBP is pushing 5 megapixels to the screen each refresh, that’s a lot of data to be refreshing to the screen 60 times a second.
You also may want to consider moving some of your functions into Core Graphics, this way you can take advantage of things like CGLayers (hardware accelerated caches). For one project, I was able to get full screen animation running at 245 fps on a Retina MBP (not a top of the range model either). By utilizing CGLayers. However it is a lot of work as you basically have to replace all your Xojo drawing calls with declares.
No clue
I’ve never seen this kind of effect when messing about with turning retina on in the IDE (there are some other effects but nothing quite like this)
Would need to poke at some code to tell
[quote=92873:@Matthew Combatti]In a screenshot from a beta tester it would appear that more than canvas is not functioning properly using retina display. Other xojo controls not displaying or working properly appear to be:
[/quote]
Did you use CGContextRestoreGState CGContext at the end of the paint event? If not, this will do strange things.
[quote=92939:@Norman Palardy]No clue
I’ve never seen this kind of effect when messing about with turning retina on in the IDE (there are some other effects but nothing quite like this)
Would need to poke at some code to tell[/quote]
If needed I can forward the raw source code for inspection. Although the native UI controls not displaying is a total mystery since no one else has retorted any such bugs, as well as the mystery window title.
Christoph-yes the declares were added properly and thank you for testing on your own time. … has been much appreciated.
Can design web builders like:
https://forum.xojo.com/13194-everweb-1-4-released-easy-to-use-iweb-replacement-website-build