Slloooooowww under Windows

I’ve stuck with compiling my Windows apps with Xojo 2015 in 32bit to avoid the messy new DLL requirements.

Some of my users are reporting that my flagship Windows app is very slow on their fancy new machines.
I test on old kit with limited resources, such as a 2010 Dell laptop upgraded to Windows 10 64bit - 4Gb Ram and 2.8Ghz chip.
It works perfectly there, and I would expect newer kit to run faster, surely?

Is there any compatibility issue I need to know about that would render this very slow on newer machines?
(I have tried building a 64bit version but that crashes horribly and I have no idea why )

Do your users have better results when your software is packaged correctly instead?

Could you expand on “slow”? Slow UI redraw speed, slow processing of some maths routines, certain controls are slow?

It is a real pain to deppend on Visual Studio run times when not using visual studio to develop. Some times you need hours of windows update to install prerequiered updates, others, it will simply don’t install.

Do you try to turn on the “Include Windows Runtime DLLs” option in the Windows Build Settings?

As @Tim Parnell Implies - what happens if you do build a modern version with 2019r1.1 as a test? Just get one of two users to test it and compare the results.

You mean apart from being codesigned and shipped in a signer installer?
Packaged how, exactly?

This is required on more recent versions of Xojo.

[quote]
what happens if you do build a modern version with 2019r1.1 as a test[/quote]
my machine usually runs out of memory. I havent succeeded in building a 64bit app that runs

This is a 32bit app.

I have narrowed the slow area down to some drawing that is done in a tight loop.
Something that takes the Mac less than a second takes 10 to 15 seconds or more on ‘some’ windows machines, but not all.
I suspect GDI libraries or video drivers.

what all is happening inside that “tight loop”… perhaps there are things that cause other events to fire more often than necessary (something that macOS compensates for and Windows doesn’t?) just shooting at stars here… :slight_smile:

@Tim Jones picked up what I was trying to say. I’m wondering if going out of your way to build without those DLLs is the problem.

[quote=445506:@Jeff Tullin]my machine usually runs out of memory. I havent succeeded in building a 64bit app that runs

This is a 32bit app.[/quote]
You can build a 32bit app with 19r1.1

Just code. Nothing GUI

Worth a try. I’ll get set up for that ( if my licence allows for it… I may only be able to do that from my Mac. But Windows apps made on my Mac just crash on a real Windows machine)

The problem code seems to be stuff like this:

Windows:

dim colsrgb as RGBSurface = mypic(x).rgbsurface for z = 0 to 63 for z2 = 0 to 63 if colsrgb.pixel(z,z2) = &cffffff then colsrgb.pixel(z,z2) = &cfefffe next next

This occurs 255 times for each mypic(x) which is an image of 64 x 64 pixels

Are you generating those images while the app is running or are they existing images that you’re just modifying to remove pure white? If the former, just do it once when the user finishes the work on the image. If the latter, why not modify them once and re-save them before you build the app?

There are an array of images and the contents can change often during the course of the app.
The content is not fixed.
Its code like that… not just replace white with offwhite every time.

rgbsurface.pixel is much slower on some machines than others.

Yes! since 2016r4 have issues with rgbsurface so I had to use pictureMBS plugin

ReplaceColorMBS(SearchColor as color, ReplaceWithColor as color) as picture

That looks promising