I recently bought an upgrade to solve a crash in 64bit builds made with Xojo 2015
I downloaded the 2017 edition.
A section of code that draws (say) 100 x 100 ’ icons ’ into a grid on an offscreen picture is now so slow I need a stopwatch to try and time the process, as opposed to ‘blink of an eye’ in 2015
Is this known about/expected?
It seems to be related to partial copying, and maybe scaling
In a grid of maybe 100 x 100 icons
[code] g.DrawPicture theapp.picturewithlotsof64x64icons, xx, yy, 30,30, theindex*64,0,64,64[/code]
Takes 11 seconds
[code] g.DrawPicture oneicononly,xx,yy,30,30,0,0,64,64[/code]
takes less than 0.5 seconds
Thats awful.
Huh… I don’t know why this would get slower. Scaling images has always eaten processor time, on the Mac you can adjust the context rendering options, normally reducing the quality of the scaling will speed it up.
declare sub CGContextSetInterpolationQuality lib "Cocoa" ( context as integer, quality as integer )
CGContextSetInterpolationQuality( g.handle( g.HandleTypeCGContextRef ), 2)
Will speed it up at the expend of quality, I and think using ‘1’ is even faster, but much worse quality.
I assume that you’re storing the icons in a larger size (64) because you use them elsewhere? Otherwise consider scaling down the large image in one go, so that the icon sizes are already 30, 30.
The other reason could also be how the OS now internally treats images, whereby it seems to no longer cache them, but re-load them from disk when it needs too (I think it still might keep a cached version at the last size drawn, and in your case, you’r not drawing the entire image). This caused me some issues with declares, until I found an option to force the OS to cache the image now.
Me neither. 
But this sums up my experience of Xojo since 2012
Have a bug - have to upgrade to avoid the showstopper - check the bug, ship, and within hours hear about a new problem in something basic which has worked untouched for years.
The Lord giveth and the Lord taketh away.
I cant use 2018 because it’s bad on Windows
Can’t use 2017 because of this.
Can’t use 64bit 2015 because it crashes in a routine that works perfectly in both debug and 32bit compiles.
Sigh
You’ve given me an idea though Sam (thank you !) , so Im going to try a radical (but wholly unnecessary) recoding.
No need to thank me, I hope it works and if it perhaps you could share it?
Nothing fancy.
Code which has worked perfectly since 2006 has the icons in a single bitmap, arranged left to right.
‘the one I want’ is N * 64 pixels from the left.
So I copy a portion( 64 x 64 chunk) from the big image on request.
The big image is already a copy of the embedded image - nothing should be getting pulled from disc at this point, cache or no.
I fail to see the practical difference between doing ‘part of a big image’ versus 'all of a 64 x 64 image’ but it really makes a difference to the speed.
The change will be to create an array of 64 x64 images and use those instead of the big image.
if that’s not fast enough, then an additional array of n x n images will need to be generated each time the on screen zoom size changes.
Precalculation.
As I say, this should not be required and hasn’t been for years.
Report the bug. Who knows where the deeper problem with drawing speed lies
I dimly remember a Xojo user who had a massive slowdown in drawing a grid. The reason was something with font names.
Ha, not yet totally senile: <https://xojo.com/issue/46020>
who would ‘get on board’ such a bug report if no-one else has been affected by it all through 2017?
It’s easy to demonstrate, but I may be the only one who cares / is actually significantly affected…
[quote=391508:@Jeff Tullin]who would ‘get on board’ such a bug report if no-one else has been affected by it all through 2017?
It’s easy to demonstrate, but I may be the only one who cares / is actually significantly affected…[/quote]
But you have a simple to reproduce MASSIVE slowdown, so that gives a good starting point to figuring out where this slowdown occurs which might also be the reason for the general slow down in drawing speed.
OK.
This demonstrates it fairly well, and uses no external images
The real code has images with masks too, not sure if that is a factor yet
First x/y loop takes 5 ticks
Second x/y loop takes 2 ticks
[code]
dim bgpic as picture
bgpic = new picture (canvas1.width,canvas1.height,32)
dim iconspic as picture
iconspic = new picture (200*64,64,32)
dim smlpic as new picture (64,64,32)
dim x, y as integer
dim k as integer
dim startticks as integer
dim diff as integer
startticks = ticks
for x = 0 to 499
for y = 0 to 499
k = rnd() * 200
bgpic.graphics.DrawPicture iconspic, x10, y10, 10,10, k*64,0,64,64
//g.DrawPicture oneicononly,xx,yy,30,30,0,0,64,64
next
next
diff = ticks - startticks
msgbox format("Time in ticks: " + diff, “0”)
startticks = ticks
for x = 0 to 499
for y = 0 to 499
k = rnd() * 200
bgpic.graphics.DrawPicture smlpic, x10, y10, 10,10, 0,0,64,64
next
next
diff = ticks - startticks
startticks = 0[/code]
Holy crap batman, the first loop takes 87 ticks, while the second takes 67 ticks on a 2012 Retina MacBook Pro, running macOS EL Capitan.
2016 MacBook (bottom of the range model) running Mojav, takes 85 ticks, first loop and only 45 on the second.
By adding “Dim g as graphics = bgPic.graphics” and using that to draw the pictures, I got it down to 83, 56 on rMBP and 66/48 on the 12" MacBook. Shocked that this POS is smoking the r2012!
I just noticed I posted a later version of the test code by accident.
I didnt get 5 and 2 with this as posted, the 5 and 2 ticks were with x/y loops of 99
My ‘real’ code already has a G variable. Im just trying to illustrate the difference between using ‘part’ vs ‘all’ of a picture.
(Im not convinced that the multiply should be costing much time k*64 )
Not sure I understand what you are saying. ( = dont understand… :> )
Are you shocked at the timings, the difference between the methods, or is the 2012 MBP model beating your current machine?
What happened here?
[quote=391457:@Jeff Tullin]
Takes 11 seconds
takes less than 0.5 seconds[/quote]
and now we are talking ticks???
The 2015 12" MacBook (Apple slowest machine) is beating my 2012 Retina MacBook Pro, which normally wipes the floor with this slow assed machine.
Metal is much faster.
If you provide a project and the test image file I can report here the results.
Heres:
MacBook Pro (Retina, 13 pouces, mi-2014)
2,6 GHz Intel Core i5
8 Go 1600 MHz DDR3
Intel Iris 1536 Mo
[quote=391508:@Jeff Tullin]who would ‘get on board’ such a bug report if no-one else has been affected by it all through 2017?
It’s easy to demonstrate, but I may be the only one who cares / is actually significantly affected…[/quote]
https://www.youtube.com/watch?v=E5Q7CcINC8M
What is so so so unbelievably sad is that it takes 343 and 264 ticks on my Windows 10 machine and 58 and 41 ticks on the same machine running a VM of macos Sierra!
You don’t need a test image Emile. Here’s the project if anyone else wants to test it:
https://www.dropbox.com/s/uz3hspx2092lagk/TestImageChopSpeed.xojo_binary_project?dl=1
It was only the other day when I began to wonder why starting the IDE was quicker in my macos VM than it was in native Windows 10 on the same machine…