Speed comparison

Targets Linux
1

Ive been trying to get some Mac apps ported to Linxu.
Most fail, but one of the less complex ones does run with some plugin calls removed.
Which is progress.

Actually, when I say run, its actually more of an amble. One area in particular doesnt qualify as a hobble.

Specifically, in one key area where I handle an array of a million integers and use that to draw 10000 bitmaps, it takes minutes on Linux where its less than a second on Mac or WIndows.

Most of the apps I have seen people do on Linux have been business-like, with a few controls and maybe database access, so I expect I’m plotting uncharted territory here.

But does anyone else see a huge difference in graphics speed and /or memoryblock access?

Test system: (recent) Linux Mint in a VM, using 2016 4.1 Xojo

2

Maybe you can write little benchmark app and than provide it for testing here?

it could be that Mac and Windows use hardware accelerated drawing while Linux doesn’t.

3

if you’re drawing things, may be it’s your VM that is slowing down things, and not only the linux part ?
can you try on a real linux box ?

4

Certainly possible.
Maybe VMWare graphics drivers for Mint aren’t as optimised.
(My Windows VM works fine with the same code.)

I do need to put together a small example project.

What I can say is that the maths part of it seems fine because drawing primitives like fillrect works at an acceptable speed.
When I get into blitting scaled bitmaps we have the issue.

And in fact, its ‘offscreen’ work.
So the copying occurs onto a picture, which is then copied to screen.
Its the generation of the picture that is the slow part.

Example code to follow shortly.

5

How much ram does the VM have available?
Is Xojo running in the VM or are you using remote debugger?
If you’re running out of ram, things will tend to bog down pretty badly in a VM.
Check the free memory in the VM while the project is running.

6

To further what @jim mckay said -

Never run a Linux VM with less than 4GB of RAM and 2 CPU cores assigned if you’re running the IDE. I’ve got years of experience with this and my VM layers run from dedicated ESX, VMWare, Linux on Linux, Fusion, Parallels, Virtual Box, and Hyper-V. Anything less and you’re going to see unreasonable runs under Linux.

Also, if your VM manager allows you to assign graphics memory, 1GB is always the sweet spot. I tried 2GB and 768MB, but 1GB seems to be the top of the bell curve.

7

Thanks for the advice
That got the section down from minutes to 18 seconds
Still no use, but improved.

Since FillRect instead of drawpicture works acceptably, that rules out the maths being done for the loop
I need to examine the code inside the loop for the bitmap and see what part of the drawpicture is holding things up.
(You can imagine the code as drawing the map area of a tile-based game.)

8

Ive narrowed it down.

The key difference is between

[quote]g.drawpicture somepic(x),x,y,w,h //which is faster than

g.DrawPicture bigpicture_holding_many_images,x,y,w,h,startposinthebigpicture,0,64,64[/quote]

So its the chopping up of a big picture holding many sprites which is the issue.
That suggests I can get some speed improvement by having the sprites as a pre-initialised array.

9

I noticed a similar thing when using Xojo.Data.ParseJSON :
what takes 0.7 seconds on a Mac can last over a minute on a LInux box.

Which renders Xojo as a base for REST webservices on Linux as useless, in many cases…

https://forum.xojo.com/37218-xojo-data-parsejson-extremely-slow-on-linux-webapp/p1#p304199

10

Wow.

[code] for x = 1 to 255
bitmaps(x) = new picture(64,64,32)

if iViewMode = 1 then
  bitmaps(x).graphics.drawpicture bigpicture_holding_many_images,0,0,64,64,offset(x)*64,0,64,64
end if

next[/code]

10 seconds for a 255 loop with a copy from one bitmap to another…

less than 0.5 seconds for a direct copy without scaling or ‘get from a certain position in another picture’

11

RGBSurface.transform doesnt produce the correct results either.
No matter what 3 values I use in the integer arrays, I’m getting a pale purple color as the result.
Linux is a hard slog…

12

[quote=315339:@Jeff Tullin]10 seconds for a 255 loop with a copy from one bitmap to another…

[/quote]
There must be something else going on. I’m seeing 1/10th of a second copying from a big image to 255 smaller images on an Ubuntu VM. (actually slightly faster than native MacOS!?)
Also seems slightly faster if you remove the ,32 from the picture constructor. Try “bitmaps(x) = new picture(64,64)”

You could try running the app from a terminal and see if any helpful messages come up.

13

You’ld think.

But that is the whole code

Does that work when debugging in the IDE?
Ive been trying to get this project working in Linux for the last 10 year.
This is the first version of Xojo Linux that has come close to running, but I’m still not convinced enough to buy the compile, even if it is only $99.
(I’m plodding through: if I can work around enough ‘unexpected features’ then maybe this time.)

14

Unexpected feature 3:

Copyfile doesnt copy (folder_support is not null, does exist, and so does eula.rtf)
No exception, but no file copied.
Neither file open in any other process.

ff = folder_support.child("eula.rtf") ff.CopyFileTo folder_support.child("newname.log")

15

[quote=315619:@Jeff Tullin]Does that work when debugging in the IDE?
[/quote]
Yes, just use the “Run Paused” option in the Project Menu.
Then you can drag the executable to a Terminal window.
Usually I see a few messages about theme parts not being found, but sometimes there’s something useful.