I gotta wonder if there’s something else going on… For instance, how much RAM does this machine have? The reason I ask is that it could be that in 64-bit mode, your app is suddenly allowed to use more RAM that you have available and is suddenly caching memory on disk as necessary.
The only other thing I can think of off the top of my head is that Apple has been moving away from OpenGL for their own Metal libraries. I do not have any experience in this area although there are other users here on the forum who do.
It gets more and more weird. I tried it on a 2017 iMac, retina of course, but very plain specs I5, cheapest video card, 8 megs of ram. The late 2012 has a better spec of it’s time with I7 3.4, the better video card available and 16 megs of ram. On the RS version they where very close in speed, with the newer being quicker by 6-7%. On the Xojo version, the speed went up by 76% !!! Still 28% slower than the RS version but really quite OK. I guess I can live with that. In numbers for the mid range sailboat:
One of the reasons the Xojo code draws slower might be that the IDE uses newer MacAPIs than RS did. While this ideally should mean better performance too, this doesn’t have to be the case in all aspects and configurations. You might find Sam’s rants about Apple deprecating CGLayer hidden somewhere here or on his blog quite informative.
You say speed is ok now. So quite unnecessary additions following:
Basically, Xojo’s Graphics object on the Mac is a wrapper for CGContext. Which in most cases works really fast, but lacks some of the highly optimized bulk drawing routines like CGContextAddLines. Depending on your usage of plug ins/declares/libraries, that might be an easy (or complicated) solution to add a performance gain of considerable size.
Not using alfa channels as there is no need for it in this application. The picture is just where the drawings are going. The drawing either starts with a blank sheet, or with another picture pasted in, containing stuff that was unchanged since the last update. This actually speeds things up quite a lot, especially when doing minor tweaking on a bigger model. Boat design, for example, typically consist of tonnes of minor tweaks
You might not be using them but if you are creating pictures they might now have an alpha channel. If they do then any graphics drawing you perform will also be drawing into the alpha channel which I imagine means more overhead.
If you create a picture via New Picture(w, h, 24) or New Picture(w, h, 32) then you will be getting the old style mask picture. However, if you create a picture via New Picture(w, h) without a depth it will have an alpha channel. It might be worth checking any code that creates pictures.
Our RB code also used graphics.UseOldRenderer to force Quickdraw rather than Quartz as it provided a speed increase in some circumstances. UseOldRenderer does nothing now.
It could be that Xojo graphics drawing now has some kind of setup / teardown overhead on each call which only shows itself when performing a lot of drawing. If you have the MBS plugins you could maybe look at using CGBitmapContextMBS for drawing to see if that is more efficient.
No, always New Picture(w, h, 32), so no alfa channel. Yes UseOldRenderer was used in the older version as was substantially faster though not quite as good looking. Yes, got the MSB plugins but haven’t tried CGBitmapContextMBS. Perhaps worth a try.
I should perhaps also say that some picture features are actually faster in the Xojo version. The program also performs massive image transformations fitting flat images into 3D shapes. I suspect that it’s just a question of the 32 bit code living very close to choking due being too close to what a 32 bit program could address. Here is an example, a 48 meter long and 20 meter high airship having a full vinyl image wrap. The print was 1.5 meters by 1.5 kilometers, divided into 1680 patches being about one square meter each on average.
Claes - I am definitely not as informed about the intricacies of graphics programming as the other people and I apologize if this is a stupid suggestion.
I had a similar problem with a reservoir simulator program I built in 32-bit Xojo. When I upgraded to 64-bit Xojo, I experienced a major slowdown in this compute intensive program. I solved the issue by placing #Pragma BackgroundTasks False in the Open Event for the program. The program returned to its original speed.
I have no idea if this will work for you - I just thought I would contribute my 2-cents worth.
Did some preliminary testing on Windows, and here the 64 bit code seems to be quicker than the 32 bit code. Say 10-20 % up. Also tried on a Macbook Pro 13 and the difference seems to be smaller than on the older iMac. About te same as on the newer iMac. I guess the conclusion must be that the gap varies a lot depending on the hardware.
This slow down is really weird. I test ran the 64 bit version on the same machine (iMac 27 Late 2012 3.4 GHz i7, Nvidia Geforce GTX 680MX 2048 MB) on the old version doing a specific drawing. The old 32 bit version did a redraw in just under 0.3 seconds, the 64 bit Mac version in just over 0.7 seconds, and the 64 bit Windows version did it in 0.5 seconds flat while running Windows on Parallells. The emulator was actually quicker than the native Mac version ???!!! Surely, this does not make sense at all in my book. I’m 100% sure that it’s the drawing alone that causes this slow-down. The underlying math grinder is as quick as before or even slightly quicker. Tested other newer Macs, and the trend remains though its not as significant as it is here.
Apple now uses triple buffering. Screen -> Window -> View. The older 32-Bit application is probably built against an older API, so Apple doesn’t auto activate triple buffering for it.
Some general best practices include.
Disable anti-alias.
Move as much logic as possible out of the paint event.
Do all your drawing directly in the paint event. Do not cache to an image first.
Ideally you should resize images to the “displayed” size before drawing them. All though this only makes a difference if you’re drawing an image once as the OS will cache it at that displayed size for faster redraws.
If you can do so, disable the views transparency.
For maximum performance on a modern Mac, you can consider Metal, but if you want to ship a Windows version as well… Look at MoltenVK.
I would also suggest, before you go down the rabbit hole of using declares and experimenting with Apple’s Metal and other available API. Don’t. If you can get adequate speed out of native Xojo, stick with that. Two reasons why.
Your application is not locked into Apple’s platforms.
You shouldn’t have to face the ■■■■ show that is Apple’s “advanced” graphics toolbox, and the horrendous state of it over the last handful of OS updates.
I agree with everything you say (and have already implemented it all in the past, more or less), except drawing directly rather than into an image. The latter has always been faster in earlier versions, but to make absolutely sure, I generated a small test app drawing lots of lines. As predicted, the image method was 10-15% faster than drawing directly.
I also agree that using the standard setup is preferable if possible. In my case, I want to maintain full Mac Windows versions with a minimum of effort, combined with having a very complex app to work with and maintain, as well as keeping up with the huge amount of consulting work it generates based on the wealth of unique features the app contains. There is simply a limit of time that can be spent on the app development.
Way out of my experience zone (what you are doing), but often when creating large result lists like - adding thousands of rows to a list - If the list is visible during the list creation, it will perform the function to a factor of 5 or 6 times faster if the list is set to Visible=false prior creating the list, then on completion make the list visible again. If you have a property like “Redraw” which can be set to true or false, this will enhance the speed even more. In your case I’m imagining an ImageView/Picture box which can be made visible or not. Please ignore this post if I’m way out.
Any suggestions are welcome. I can imagine that it can have an effect in lists. I did run it in my very simple test program it did not seem to do much of a difference in this particular case anyway.
