I have developed a game using Xojo, and it mainly uses Canvases and Labels to display images and buttons. No complex drawing of any type, though a few of the images are somewhat large (800 KB or so). I’m using Custom UI and that’s it for plugins, and its using 2014r2.1.
It performs well on my system and most other systems, but some users are reporting lag when clicking on things and changing screens and windows, delays in click responses, etc. What can cause this in Xojo and how can I minimize this sort of thing? This is for Windows. Frame type for the windows used is Shadowed Box, and GDI+ is turned on.
Depending… you may find a huge increase in speed (at the cost of threads, and XOJO doing some error checking)
Also, if you are using one or more canvas controls, consider using a PICTURE object (or multiple ones) to cache portions of the image that change less frequently (backgrounds for example), update from the picture instead of doing all the time consuming drawing in the PAINT event.
[quote=176987:@Derek DiBenedetto]I have developed a game using Xojo, and it mainly uses Canvases and Labels to display images and buttons. No complex drawing of any type, though a few of the images are somewhat large (800 KB or so). I’m using Custom UI and that’s it for plugins, and its using 2014r2.1.
It performs well on my system and most other systems, but some users are reporting lag when clicking on things and changing screens and windows, delays in click responses, etc. What can cause this in Xojo and how can I minimize this sort of thing? This is for Windows. Frame type for the windows used is Shadowed Box, and GDI+ is turned on.
What are the best tips for this sort of thing?[/quote]
Without seeing the app its kind of hard to make recommendations for “best practices” beyond what Dave’s already mentioned
Thanks for the tips, Dave. Yes, the code itself isn’t too involved overall and pretty well optimized. But its odd that on some systems it runs well (mine included) and on other systems it’s laggy. In general, what can I do to keep things smooth on almost all systems?
One user says they experience a 10-15 second delay when they click on something, but if they set the game to XP SP3 compatibility it drops to 5-7 seconds. What could cause that?
The big unanswered question here is how much RAM the user(s) witnessing the lag has in their system. I’ve got an app that runs fine - even on old 1GHz Celeron processors - as long as the system has MORE than 2GB of RAM. If the box has 2GB (or less ???), the whole app is a serious exercise in patience.
The user says they have 6GB of RAM and a i7 processor, which seems odd. They use ESET virus protection as well, not sure if this is an issue. Do any of the canvases or graphics stuff built into Xojo use OpenGL 3.0? They claim their video card has issues with games that use this.
If they’re running 6GB, it implies a mismatch in SDRAM chips (i.e.: 1-2GB and 1-4GB). Not all motherboards deal with this type of mismatch pairing successfully as the DDR3 spec is dual channel and expects 2 DIMMs of the same specification and size (this is why Crucial, Kingston, PNY, etc. all sell matched pairs for best performance).
Antiviruses are notorious for slowing down disk access, but usually not graphics. The card is a more serious possible culprit. A badly designed graphic card can be a serious bottleneck.
Back in 2006 we made several x-plat games with Xojo. Rather than using separate controls, we used a single Canvas or OpenGLView.
The single canvas route allowed us to cache the contents to a picture for full page animation or only to update certain areas for specific region animation. Back in those days, game updates were actually smoother on lower powered Windows machine than a OS X machine.
Once we started using CGLayers (which Apple have since abandoned) we then saw superior performance on the Mac over Windows.
If controls are too close together, a repaint of one can cause a refresh on the one next to it.
This can cause a cascade effect where you end up with many more paint events than you expect.
If you can, swap the labels for .drawstring in the Window’s paint event.
If you can, do the same with the canvases: nothing to stop you doing the same drawing in the window Paint event that you were doing in the canvas paint event: all the canvas is likely to be adding is an ability to offset the drawing by the canvas top and left co-ords.
This is the reasoning behind Sam’s
where he did the same, but kept one canvas instead of drawing to the window.