Analysis of Xojo’s Bug Tracking System

So which bugs are showstoppers for you?

2 Likes

This. It’s the showstoppers that matter most as they stop you from moving forward and they are rare. When users contact us with a showstopper, the first thing we do is see if we can find a workaround because that will let them continue. If there is no workaround then we try to get it fixed for the next release.

8 Likes

Windows framework graphics / UI performance has become a showstopper for us.

1 Like

In what ways? Can you point me to issue numbers so I can look into this? We are working towards migrating our Windows framework to WinUI which perhaps will resolve the issues you are having.

5 Likes

Any Windows app that draw more than a few controls is noticeably slower since the transition to Direct2D. The more controls, the worse it seems to be. We have an Inspector panel that contains quite a few controls and it is significantly slower than GDI+ versions of Xojo.
The same slowdown can be seen with the Xojo IDE on Windows.

Trying to pinpoint the cause of the problem is difficult as there is no easy way to profile the running code at a low level like you can on macOS via Xcode Instruments.

However, here is one of the bugs we reported a few months ago. The case mentions minimising / maximising the window because it makes the problem easier to see. The performance issue does seem to occur any time controls are redrawn though:
https://tracker.xojo.com/xojoinc/xojo/-/issues/76798

Here is a bug we reported 4 years ago which was supposedly fixed:
https://tracker.xojo.com/xojoinc/xojo/-/issues/61859
The fix didn’t improve things so I logged this case:
https://tracker.xojo.com/xojoinc/xojo/-/issues/74622
Unfortunately, I was then told that this only worked with v2 controls. Just to test this fix we would have to spend a significant amount of time re-engineering controls and code that are shared across multiple windows to make it v2 API compatible. The time spent on this would be wasted as we don’t have solutions to other problems yet.

This one is not mine:
https://tracker.xojo.com/xojoinc/xojo/-/issues/67866

We do have several other show stopper issues that occur in newer versions of Xojo but we are rewriting the relevant code where possible to avoid them.

Maybe the transition to WinUI will help but from the information William has provided over the years I get the impression that Xojo does a lot of things at paint time in the D2D versions that it didn’t do in the GDI+ versions which is at least partially responsible for the problem.

2 Likes

Well said Kevin,

I can’t find my old request for Graphics and OpenGL issues with Xojo, as it was many years ago and likely removed when transitioning to the ‘new’ issues bug tracking system.

Here are the aspects that I found and workarounds which caused me to write three plugins and here are the explanations to cause Xojo to have good performance on Windows, just like the good performance with Java, Python,and C++:

  1. Moving the mouse over a Xojo window caused the graphics speed to increase on Xojo drawn Canvas and OpenGL. After creating a WinXojoPlugin to implement a couple of Xojo calls properly in C++, then the performance increased with increased reliability.
  2. Constants and some methods were missing in Xojo for OpenGL, and I rewrote and upgraded OpenGL to 2.1 with the OpenGLXojoPlugin Windows 64-bit version. This increased performance and increased the number of missing constants in the OpenGL plugin from Xojo.
  3. When I created my own windows and canvas with the GLFWXojoPlugin, then almost all of the performance for drawing returned. If I were to embed the GLFW window into a Xojo window, or call a Xojo graphics command with the GLFW window, then the performance would dramatically slow down and graphics studdering would return.

Using all three plugins to ensure proper Windows calls worked extremely well. I wrote a book on how to use the plugins and bypass Windows GUI in Xojo to ensure that graphics for my customers was good and reliable.

I even did a teaser video on YouTube: https://www.youtube.com/watch?v=YR0PEtWJ6N4&t=1s&ab_channel=EugeneDakin with the increased visual results and further explanations.

There have been issues with Windows and Xojo graphics for a VERY long time. I hope that my results can help Xojo return back to good graphic speed and reliability with my findings.

Eugene

5 Likes

@Geoff_Perlman’s remarks about surface area are spot-on. I think the OP’s report would be much more meaningful if it broke out the bug stats on a product-by-product basis rather than lumping all of Xojo into one bin.

IDE & Framework
Mac Desktop
Win Desktop
Linux Desktop
Web
iOS
Android

If I’m only developing on, say, Desktop, the fact that there are bugs in Android doesn’t bother me overmuch.

11 Likes

@Julia_Truchsess Excellent point that the relevance of what areas the issues are in is what is going to matter to each individual rather than the entire number of issues as a whole.

2 Likes

Are you using Declares or in anyway mixing GDI+ and Direct2D? From your report it looks like the primary issue is with containers. Is that right? Also, it would seem like you could reproduce this issue in a sample project. Has that not been the case?

1 Like

We do use GDI+ declares in a few places but we now have code to prevent them from being called when compiled with D2D versions of Xojo. This leaves a couple of places where we perform graphics related declares such as: BitBlt and FillRect within a WndProc but these won’t be getting used where we see the performance problems.

Some of our more complex controls do use container controls and our Inspector is also container with its controls sitting on a PagePanel so maybe container controls are the cause.

Both of the cases I mentioned in my earlier reply have sample projects attached.

I developp a MemoryGame for a long time. It deals and flip cards, 10 or more years ago, it was vary faster on Window, but one day it changed and it is a little faster on Mac. I suppose changed the framework?

Just a heads up to folks following this thread, that the discussion has spilled over to the comments in this ticket:

59520 - debugger skips break points

3 Likes

You mean: “dismiss”

No, I believe my spelling is accurate.

[DISCLAIMER: Post not made with AI]

1 Like

I found this so-called report to be a confusing word salad. Did somebody instigate it? Geoff, did you all contract for this? The repeated “All software has bugs” seemed like a high schooler wrote this under time pressure.
Ken Whitaker
Leading Software Maniacs

Geoff
We are all happy for Xojo 2024r4 Release Notes
Windows: DesktopMenuItem: Hiding and showing a submenu now correctly displays all the items within that submenu. (77887)

it’s not critic but I think something is going on there that I can’t understand. Second time this year release notes saying bug fixed but is not. Is it a commercial maneuver? Time and resources of both parts Xojo and customers are througn away by reporting and fixing.

Menu’s are not in same order, some submenus not working, and even a duplicated empty submenu. How many out there like me are reporting for what?
SOURCE:


Xojo 2024r4 OUTPUT:

Looks like William is working on this one right now.

1 Like

May this sample project can help to see the issue:
https://tracker.xojo.com/xojoinc/xojo/-/issues/78076

1 Like

I am locking this thread. Regarding the specific issues mentioned in the thread please continue the discussion in the related Issues cases or in the proper forum channels. We appreciate your feedback on these cases and helping us improve Xojo!

PS Xojo’s annual review blog post is coming next week and it will share statistics on bugs fixed in 2024 (among other stats). I look forward to sharing all this data with everyone :slight_smile:

10 Likes