We developed an app in 2019 - which took now about 2 years. At the beginning we made some proof-of-concept studies. These also included some tests of the UI capabilities. Now, after a bit more than two years and a few Xojo- and Windows releases later nothing works any more like it should. In fact we will not deliver a Windows version because it would be too embarrassing.
Here you see an image of the Mac-Version of one of our UI tests - very nice:
Using the WIndows Version it looks different first:
A bit strange is that transparency works at the background, but not at the overlapping part (red bubble). OK, that would not be too problematic - if we make compromises. We can see, that the app works fine on the Mac - but on the PC moving bubbles around jerks. Also if you click into a bubble it takes about a second until the selected bubble lights up.
If you switch off the background - IT WORKS FAST again!
We prepared a small sample App, which allows moving and selecting one of two bubbles. Simply drag the bubble with the mouse after opening. Do it fast. Select either bubble. Do it again. Now check out Mac and Windows. Old Windows 10 and Windows 7 will do. Newer versions NOT. Something has changed - and not to the better. If you use the button “Toggle Background” you will see the difference.
PM-UI Source Demo on Github
I do not know if this is a Windows issue or if this is Xojo. It may even be possible that I did something really stupid or I made unneccessary steps (The Paint event was not used). What has changed since the first test is, that this “double buffering” thing is gone and now “composited” is there. May be it has something to do with that. May be not.
So we are very desperate now because even Christian was not able to help us. There is a ticket open about this issue - Number 67757 (not public) and I put this here in another one. We hope that someone can help us.
<https://xojo.com/issue/67866>
The latest versions of Xojo for Windows do not provide actual transparency, but only pseudo transparency. In other words, as you saw, the control looks transparent over the background, because it takes the same color.
This is the result of Xojo implementing Direct2D. True transparency for any control is no longer available.
There could be a way to get transparency with a canvas, though.
See \Example Projects\Platform-Specific\Windows\WindowShape.xojo_binary_project
This project shows how to make a transparent window of any shape. You could do the same with a canvas.
Thank you Michel - I saw this demo and I know that. As I wrote - this would be a compromise. We work with container controls here. The other issue is a showstopper. The App is not usable any more with a background switched on. 
Even on macOS I would never work with container controls in that way. I’d always use a single canvas.
Why can’t you use Xojo 2019 for your Windows version?
This is a sample only. There is more behind - lot more bubble types, objects, methods, properties and so on. And it works really nice. On the Mac. It would be a tremendous effort to re-design the complete code.
Xojo is cross-platform - or not?
Btw: I like to stay with the newest Computer, operating system, development environment. Call me cazy, but I piled up enough technical debt in my carreer. Not any more. It’s like a time bomb … 
Here a video with the problem shown in action:
Problem Video
I believe it is a serious bug. 
There always have been differences between the platforms. Even on macOS I can see problems in your example. Using a single canvas is your best bet.
1 Like
Well, even if they denied for many years, the Xojo graphic issues are XOJOs issues.
1 Trust Xojos promisse of being multiplatform
2 not having read xojo documentation where they state those problems (blaming windows of course)
3 The overall design. As Julia says, this should be done in a sinlge canvas.
4 not having read the documentation where they say that you should NOT overlap controls on windows
This transparency issue was “by design” (blaming the OS) so expect your case be closed with that conclusion.
Well, acording to some posts, Xojo was considered technical debt by several risk assesment firms.
Again, this is considered the “by design behavior” by xojo.
Unfurtunatelly, with the current state of xojo, (current behavior and the attitude to say that this is the correct way) there is nothing that can be done without a major redesign.
I forgot to tell you the method in the example works on a ContainerControl, which is underneath an embedded window.
At any rate, I suspect it would work with any Windows control, as for Windows, any control is treated internally as a window.
The only other workaround would be to revert to a previous version of Xojo. Personally, I have projects that could not be refactored for Direct2D without a huge amount of work and terrible waste of time. I have been using 2016R3 ever since, as it offers true transparency I need. So far, the generated executables are good enough to work perfectly under Windows 11, and are a good sell in the Windows Store, after having been converted to the New API with the Desktop App Converter.
1 Like
This has been known about since 2016 so I’m not sure why it wasn’t spotted during your testing in 2019.
Unlike WinForms, Xojo took the decision to NOT lift a copy of the image from behind the control and use that as the background on the new control, thus making “truly” transparent controls but took the decision to only lift from the parent control and use that as the controls background which causes the issues you see here.
I mentioned this 5-6 years ago when the “new” system was implemented to stop the years of flicker issues but it was never discussed and I believe the ticket about it is either still open or closed as by design.
I’ve lost count of the number of tickets I’ve put in about optimising all this, fixing issues etc. but many of them are now archived and/or still open and unresolved.
I’ve lost track of how the system now works as I lost interest in arguing about it being wrong or substandard so all the suggestions I’d normally put forward haven’t been tested in years.
The only suggestion I can make is remove all transparency where possible and let the background of controls be automatically picked up from their parent, this alone will start improving the FPS. As for the edge issue, I’m sure someone posted a bit of code about doing this but I can’t seem to find it, here’s something I wrote for you a year ago that is a total hack and nowhere near perfect. There’s also an example is platform specific windows that you could apply to a container instead of a window but it wouldn’t allow for smooth edges.
Personally, I’d refactor the whole lot and go back to a single canvas as its all custom drawn stuff anyway, it’ll be so much quicker in the long run, just because you can embed controls upon controls ad nauseum, it doesn’t necessarily mean you should, even if it does “work” on the mac.
5 Likes
Maybe you dont have to refactor all. Making use of the hacks Xojo is already using you can archive with little changes Improve speed to have a usable product.
-
Move the “BubbleFrame” to 0,0 and make it the Height and Width the same as the container, adjust the inside controls (that margin is problematic wasted space)
-
On every single container add in the open event(improves speed):
#If TargetWindows
Me.DoubleBuffer = True
Me.Transparent = False
#Else
Me.DoubleBuffer = False
Me.Transparent = True
#EndIf
- On every single RoundRectangle add in the open event and remove all corner setup code in the parent (Improves speed and removes round corners):
#If TargetWindows
Me.Transparent = False
OptionFrame.CornerHeight = 0
OptionFrame.CornerWidth = 0
#Else
Me.DoubleBuffer = False
OptionFrame.CornerHeight = App.s_CornerRadius
OptionFrame.CornerWidth = App.s_CornerRadius
#EndIf
- For the “MainBubbleContainer” add in the open event:
#If TargetWindows
Me.DoubleBuffer = True
Me.Transparent = False
#Else
Me.DoubleBuffer = False
Me.Transparent = True
#EndIf
4a For the MainBubbleContainer “transparency”:
Add the event handler Paint to it And in there paint just part of the the BackgroundJPG picture, use the “sourceX” and “sourceY” to cropt the picture using MainBubbleContainer.top and left this is pseudotransparency, MainBubbleContainer is NOT transparent but it has the the correct background
Notes:
-Allways create a subclass of your controls and use that, that way wen you encounter one of the many, many Xojo shortcomings, you aply the workaround in a single place, the Super instead of on every single one of your controls.
-You should change the color of the “BubbleFrame” in the selected Bubbles to avoid confusion with the Bubbles bellow.
Ivan,
thanks a lot. I tried a bit around with what you suggested. First and most important issue is that the DoubleBuffer property is gone in my Version 2021 R3.1. If I use your code I get:
Type "BubbleSelection.BubbleSelection" has no member named "DoubleBuffer"
Me.DoubleBuffer = True
Which is obviously true. As I mentioned: In old XOJO and in old Windows it works. This was the foundation on which we started to develop. Based on your suggestion I used this here at all “Opening”-Events then:
#If TargetWindows
Me.Composited = True
#EndIf
But it did not change anything. The only real impact happens if I remove the “Backdrop”. Thank you for all the other tips - the App is ready and already had most of your suggestions implemented. I stripped the old UI-Test down to show the problem only.
So if it is possible for you could you please try with the latest XOJO and Windows? And if your improvements work, please would you check, which one made the big difference?
Thanks a lot for your great help!
Right, the API2 namig fiasco was not enough, now we have the API2 “new” controls that are the same but a mess…
Well, I can tell you that I tested in your proyect with Xojo 2021.3.1 and the DoubleBuffer option worket there because those were API1 ContainerControls, if you get the “has no member named” error it means you are using the “new” API2 DesktopContainer.
Im sorry but I have not the time this days to rewrite the sample using API2 and test. Composited should behave the same as DoubleBuffer but I havent used the “New” controls, maybe works, maybe not. I only can tel you that it works in Wojo 2021.3.1 with API1 controls.
Some advice, by commons sense and experience: DONT EVER TRY TO USE A NEW XOJO FEATURE for production. They almost never make things right the first time, it takes serveral releases (1 year or more) to have new features in a usable state.
4 Likes
Did you noticed the 2021R3.1 new project file format ?
Even 2021R2.1 cannot read a project created with 2021R3.1…
Could it be this is related to backdrop painting whole picture always?
Like if you draw the picture via Paint event, the drawing can be clipped and be quicker?
Looks like in our tests that drawing picture in paint event is faster than having it in BackDrop property.
Can you check @William_Yu , how you guys handle Backdrop in window/container?
1 Like
We draw it without “clipping” if that’s the detail you are looking for.
@Michael_Dettmer We do not encourage the use of the Composited property as this will significantly impact refresh rates. The only time Composited may be useful is if you are scrolling content that contain many controls.
1 Like
Would an example of this be a Container full of a canvas, with controls on the canvas? Scrolling this works OK under macOS/Linux but no longer under Windows. Scrolling or indeed moving the container now produces horrible effects under Windows (on real hardware, too, not just in a VM).
Composited helped a bit in that situation but I’m having to try alternatives.
2 Likes
We use this technique with our own Inspector (it contains many controls). However, we only enable Composited when actively resizing and immediately disable it once resizing stops.
My replacement (if it works) will consist of two canvasses side by side in the control and then I draw the text that would have gone into the controls, on the canvas. Two canvasses because I need to create the effect of a hanging indent, can’t do that AFAIK with g.DrawText.
To be true: If I remove all .composited=true from my code I can see how it builds up every container second by second. After 5 seconds he is ready. Mac works in a fraction of a second. Profiling shows me it is obviously outside my code.
Thanks for taking care of your customers …
