So you see the slow down with a single user using RDP?
RemoteFX might be something that you can look into to offload some of the GPU load to the client machines (this obviously depends on the clients PC specs as if they are running extremely thin clients then this wont help). However I’d only even consider using this if you’re doing 3d heavy rendering, which it doesnt seem that you are.
You mention that you’re seeing flicking controls. When this happens twice the bandwidth/graphics processing will be happening because it’ll be sending you the image from under the control and then the control to draw over the top (this is why you see the flicker). Are you using something like a background image on the form or layered controls in some way?
Are you able to put together a small sample app that exhibits similar problems? Maybe just throw the same number of controls on a window in a new project and populate a listbox with random data to emulate it and post it here for some testing by others?
[quote=343228:@]So you see the slow down with a single user using RDP?
RemoteFX might be something that you can look into to offload some of the GPU load to the client machines (this obviously depends on the clients PC specs as if they are running extremely thin clients then this wont help). However I’d only even consider using this if you’re doing 3d heavy rendering, which it doesnt seem that you are.[/quote]
In fact the users works with very basic thin clients, so I guess this is not needed.
Sure there are layered controls. And many controls also live on a PagePanel. Container controls seems to suffer even more…
I did this already, opened a Feedback issue with movies showing the difference. Creating an example app would require some time, to strip all the database stuff, etc. but I can try.
I’m sure I had another one, but can’t find it anymore.
Problem is building a working example needs some work.
And still, I don’t get why a VM is now much slower than before. I’ve never seen a single program being slow under VMware Fusion or Parallels.
And about Windows Server, we have customers using Adobe Illustrator on a thin client without problems. Apps built with Xojo 2016r4+ do have problems instead.
[quote=343245:@Thomas Kaltschmidt]“Hmm, das spricht Bände.”
If even graphic intensive programs like Illustrator works ok, then your server/setup should not be the problem.[/quote]
I see, well in fact I’m pretty sure it’s not a server configuration problem.
As I already said on the aforementioned feedback case, I don’t really understand why a fallback mechanism was not implemented to use GDI+ when hardware acceleration is not available.
This was done for the printing part, so I guess it could have been for the display too.
I understand the above can require some work and trade offs, but seems more consistent with the approach on which Xojo always insist: don’t break old code.
And this almost broken our 50+ enterprise applications.
[quote=343245:@Thomas Kaltschmidt]“Hmm, das spricht Bände.”
If even graphic intensive programs like Illustrator works ok, then your server/setup should not be the problem.[/quote]
Spot on, thanks
Out of interest, have a look at task manager when you are performing a window resize and see what your logical processor jumps to that the application has been assigned to.
Also go into Details in task manager and sort by the CPU column and see what the application does on that list. Let me know the number it peeks at and the number of logical processors you have.
For example, I have a basic form with 16 text boxes, 16 buttons, 16 labels and 16 ovals and during a resize I can hit 90% on a single core on my i7-6950X. When I run the same program on a Windows 2012 server via RDP I start to see the labels flicker and the logical processor is pegged at 90%+.
Not very scientific for such a quick test but its showing the issues are with re-positioning/resizing a large number of controls.
We must issue BeginDraw / EndDraw calls for D2D to draw at all
Whether you have access to those calls is a different issue and is your question on that post
Where possible D2D is hardware accelerated
It IS possible to have hardware that does not support it and so Windows uses software emulation
[quote=343283:@Norman Palardy]We must issue BeginDraw / EndDraw calls for D2D to draw at all
Whether you have access to those calls is a different issue and is your question on that post[/quote]
I threw it in there as a poke if someone was reading that had missed my post, I should have put it on another line.
[quote=343283:@Norman Palardy]Where possible D2D is hardware accelerated
It IS possible to have hardware that does not support it and so Windows uses software emulation[/quote]
It’s also possible to code your D2D routines to render to software even if there is hardware to support it or have it forced to software depending on that routines you use.
So, if the card doesn’t support hardware acceleration we should be expecting a draw rate of less than that of GDI+ or whatever the previous rendering method was called for Xojo?
Guess you have a very hard time to find one without hardware acceleration, even integrated graphics on the CPU use it for a long time now. Of course i agree this special case is very unfortunate. But maybe there is more involved, hard to say.
Massimo, i just did a few tests with Windows 10 in Parallels Desktop 12 on Sierra. I deactivated 3D-Support in the graphics settings of the virtual machine, to get software emulation for D2D. I tested the example AnimationExample (with Canvas) and the FileBrowser example (with Listbox), all built with 2017r1.1 on the Mac. Of course it is getting slower, but not more than anything else. And it is far away from not usable.
So maybe in your setting there is something special different and may it has nothing to do with D2D at all? Guess you only find out with a lot of tests and checking all details on different soft- and hardware. Since you are saying that you see the slowdowns in your apps in Parallels as well, may try the demo samples i mentioned to check them, at first.
Massimo, from my testing tonight I can’t put my finger on the differences between pre and post D2D with regards to your speed issue. I can only assume that the hardware you are running on is pretty border line with GDI and that D2D has a little more overhead/requirement and that is exacerbating the issues. This is being highlighted by the number of controls you have on your form during the resize but it doesn’t address the issue of the OP about a noticeable slow down in D2D but as he’s not come back with a demo program I can’t really address/comment on that. What I can speak about is what I’ve seen in my testing tonight.
What I have found out is some issues with the framework and how best to get around them until they are fixed.
If you can get a demo uploaded of your form I’d be more than happy to run some tests on it and send it back to you if I can improve the render speed. My findings here are really just speculation as to what you’re experiencing as there could be more going on with your form than my test form.
Here is results of 2-3 hours of testing put into a 10 minute video, I hope it helps you. I’ll have a search for the feedbacks relating to the problems I’ve highlighted and put in some tickets tomorrow if they don’t exist already.
