@Paul Gaspar - have you tried splitting the difference and using 2016r3? Many of us are sticking with that for Windows until things are sorted in a future release of Xojo’s Windows framework.
Being “grown up” sometimes means exercising some self-control in the interest of civility. I’m no prude and can swear with the best of them under appropriate circumstances, but the f word has no place here imo.
Now can you change the title?
We seem to be pretty split on the matter. Some of us find censorship to be disrespectful to the author’s feelings and intents, while others find language used to be disrespectful to them as a reader.
While I fall into Category A, I think it’s best we lock this topic and if Paul has any other questions after separating out his drawing and profiling, he’s welcome to start a new thread.
This, IMO, would be overkill, because WTF can stand for “Worse Than Fail” and your interpretation of the acronym is entirely up to you.
Edit: Fix’d a grammar
doubtful that was the part of the title she had in mind
From https://forum.xojo.com/38522-forum-etiquette-and-notices-2017
1. Do not use abusive, obscene, vulgar, slanderous, hateful, threatening, sexually-oriented or any other material that may violate any applicable laws.
…/…
4. Be civil when posting conversations or comments. For example, constructive criticism is good, but name-calling is bad.
Thanks for sharing the guidelines, Michel. The language was offensive to many and yes, we do have students on the forum, so we’d like to be courteous. But, let’s move on… Back to the original topic.
I changed the title back since it really didn’t violate the guidelines.
In the future, you could do these 40 drawings in background delegating it to another processor core and send a refresh event later to the UI counterpart. It’ll be a game changer for Xojo on Windows.
Actually, this is already possible from a helper app. With an IPCSocket to communicate between apps, it is fairly easy to do.
The only limitation I bumped into is that helpers cannot be used in Windows Store DAC apps.
And Speed, IPC is a ridiculous option for exchanging something like a large bitmat, ask a helper app to do 40 modifications, receive it back, and present. Instead of running a routine that starts with the data ready in memory, do it all right now without latency and present the result just after… besides being forbidden by secure environments like app stores. https://books.google.com.br/books?id=aW9jAQAAQBAJ&printsec=frontcover&hl=en-US#v=onepage&q="true%20threads%2C%20which%20are%20always%20a%20better%20choice%20than%20"helper"%20threads"&f=false
You have to use sockets to communicate with a helper app to get multi-core processing. Xojo is limited to one core. Michel was trying to elaborate on your point, but in effect, you’ve shown that Multi-Core drawing is not possible with Xojo in an app store or secure environments.
Yep. I know. I have requested real multi-treading for years. Just explaining why again.
I dont know a single student who would be offended by anything that was in the original post (note that Paul did not insult anyone), but a lot who would be offended by the reaction.
Ah I understand. However, you can’t make promises like “in the future” unless your feedback case has been marked as Implemented.
Yes I can. Like I said we needed 64bit. It’s a kind of do it or die. Just choose the “when”.
The options are “do it” or be the only one thread language around (die).
“Being implemented” eliminates the “in the future”; your argument is illogical. 
Good morning (it’s now morning here in Germany),
first of all: if somebody felt personally offended by my words, please accept my apologies. I simply was in German direct conversation mode and forgot to switch to US rules 
@Jason Parsley, @Dana Brown: Feel free to modify the title.
@Paul Lefebvre: Ok, you are right, Xojo docs are not outdated on this. Anyway this was tricky: There is no slowdown at all on MacOS, so that was quite a surprise that Windows was messed up. Autocomplete is not always 100% accurate, so I don’t care if it does not appear. I have read a lot of documentation pages before posting here, but obviously did not find the right ones … I did not read any Canvas.Graphics docs because I did not had the idea that this is the problem.
BTW there is a not missing here : “Do use the Graphics property of the Canvas to draw in the canvas.”
@Tim Jones: Using 2016 is no option for us, we need 64 bit and other stuff from the current versions.
@Rick Araujo: Using a helper process would be overkill in this case. Speed was ok until it got slow by the Canvas.Graphics issue. Besides this, I strongly support your demand for real multithreading and multi-core support.
@Michel Bujardet , @Tim Parnell: I’m on my way building a small test project to figure out the usage of backdrop for this situation. Will post my results.
@ all of you: Thank you for your support!
So the backdrop trick works fine with non-retina. But I can’t get this to work @2x.
Here is a small demo project:
http://downloads.revolversoftware.com/dev/canvas.zip
I created an InxedImage:
[code] dim img As new Picture(w, h, Array§)
mainCanvas.Backdrop = img[/code]
But any attempt to access this image fails:
g = mainCanvas.Backdrop.IndexedImage(0).Graphicsresults in g = nil
Is this the right approach?
You need to use a picture, just like you did in non Retina. Not an image. Images are immutable, so of course it won’t work.
What you also need is to detect if you are in Retina mode to make the picture with twice as much pixels on each side.
I found that one of the easiest way is to get g.ScaleX in the Canvas Paint event handler.
CanvasScaleX = g.ScaleX //CanvasScaleX is a property of the window or a module
Then you can do
p = new picture(Canvas1.Width*CanvasScaleX, Canvas1.Height*CanvasScaleX)
Canvas1.Backdrop = p
Note : p must have enough scope to stay alive, so I would make it a property of the window supporting the canvas, or of a module.
I have updated the demo project (same link) with two more modes:
Storing a picture named “buffer” and draw it to the canvas paint event into g. This is working!
The old, forbidden way: Drawing to Canvas.Graphics directly (just to see the difference). Terribly slow.
But it is interesting to see, that drawing to Canvas.Graphics directly results in better quality imo.