64 bit build much slower than 32bit

Targets Windows
1

Well, I built a 64bit version of my app using Xojo 2021
The graphics work in a canvas is better than it has been for years.
However, nearly everything else is sluggish and slow.
For example, I show a modal window and the parent window goes blank in places.
Show a window and I can watch controls resize themselves
I do big loops of calcs looking at pixels, and its 3 times slower

This doesnt happen with the same code built in 32bit using 2015

Compared to a 32 bit build with Xojo 2015 everything just drags.
It’s not unreasonable to have expected the opposite, is it?
Disappointing.

To save memory, one of my structures uses a million bytes, treating each as a UINT8
I guess I could promote these to UINT64 - that should help?
But it would quadruple the memory used in use, I guess

Not looking for ‘an answer’ as such, but if anyone has any experience/advice ?

2

Have you tried building 32 bit using Xojo 2021?

If the problem still exists then it is probably due to the switch from GDI+ to Direct2D.

You should be able to improve the performance in some areas by making sure your controls don’t have the Transparent property set.

1 Like
3

In my experience compiling to 64bit for both macOS and Windows is faster in every aspect.
Are you using the latest Xojo version?

4

Are you using the latest Xojo version?

People ask that every time this comes up :slight_smile:
I’ve tested every year

Nothing compares to Xojo 2015
This build was Xojo 2021R3
Has 2022 has suddenly got faster than 2021?

5

Interesting. I’ll give it a try.

6

Gave it a try.
Still meh.
So it’s probably the result of LLVM / Direct2D

In my experience compiling to 64bit for … Windows is faster in every aspect.

Perhaps it is faster than 2016,2017,2018 etc

7

Unfortunately, with the transition to Direct2D you have to put some work in to account for the differences. If you are lucky you might even be able to get it working at a similar speed as before.

8

Four years ago I posted this:

Turn off transparency on all controls if you can, even one control with transparency on will cause a performance hit.

Hopefully Modern UI will improve all this, not sure when it’ll come though.

1 Like
9

You will have to rewrite your canvas.paint events. Last year we created a spreadsheetcontrol with database-connection and xojoscript. And we had to rewrite the paint event of the sheet multiple times. In older versions of RB/Xojo you could just add code in paint as you went along. Now you have to write code to fill the canvas from top-left to bottom-right. If you write the loop(s) tight enough, the speed is very good again. So no jumping from one part of the canvas to another.

10

As far as I know, this was always the case.

11

I’ve never heard that one before.

12

Same here.

13

Try compiling as aggressive. The IDE benefitted by that in leaps and bounds.

14

What didn’t you hear before?
Coordinates in a Canvas control are always top/left to bottom/right.

FWW When using NSView, it is bottom/left to top/right.

15

Except the user is in a region where they read from right to left :wink:

Seriously now: Why should I draw from top-left to bottom-right?
I have to draw from back to front and what can also help is to only consider the new area to be drawn and not draw everything each time.

16

I know about the coordinates, but the original post said to draw from top-left to bottom-right.

17

I’m sorry. What I meant was: you need to sort the objects you are going to place on the canvas on xy coords and after that draw the objects. It takes longer for objects to draw in a random order/places on the canvas, at least with many objects.
You gain a lot of speed with right drawing order. At least we found it to be so…