Xojo/Windows 7 DrawableD2D.cpp Error

image

Xojo 2019r1.1

Interestingly, I’m not using any bitmaps (at least I don’t think I am), which is what all the Xojo forum stuff talks about with this error. I have some icons on my main window, but that’s not when I receive this error.
My main program window loads properly, but when opening a 2nd window which contains a listbox, I get this error.

On x32 build (running on x64), this error comes up but the program keeps working. On an x64 build, I get the same error, but the program closes.

How to fix?

This may have been fixed in June, so you may need a newer Xojo version.

Creating a picture failed somewhere.

What sort of pictures can cause this?
AFAIK, all I have for images/pictures are a dozen or so icons, each about 12kb.

Can loading a large JSON file cause this? I have 1.5mb JSON file

All of these things are loaded and used in the main window. The 2nd window (that I open manually) has no images/pictures of any kind, and that’s when the error appears.

I’m not upgrading anytime soon. Xojo 2019r1.1 is the 2015 MBP of Xojo versions.

Do you specify bit depths when creating pictures ?
Possible any dimensions are 0 ?

I had a couple of customers run into this error with my software. We found that their machines were older hardware and had two Graphic Cards (usually some “Intel Integrated Graphics” and a “High Performance Card”, such as NVIDIA GeForce, AMD Radeon). We had to use the NVIDIA/AMD configuration tool. It had a settings panel to configure which application is using which graphic card(s). We added the executable filename to the list of Applications that will run on “Integrated Gaphics” (not the “High performance” one), and then the application was able to launch and run without issues.

This is perhaps related to: https://forum.xojo.com/t/d2dgraphicsbacking-error/42349

@totusoft suggestion is there as well as some potential new method by Jurg (which may require a newer version).

Thanks for the link languer. I couldn’t remember where I had found that info. It seems to be a pretty rare problem. I’ve only had two customers in the past four years that’s had this issue and this fix worked for both of them.

(Still can’t quote your message)

Umm… how do I check that?

Interestingly, I do have an old laptop with dual nVidia/Integrated graphics. I thought for sure this would be it, as I have no large images or anything. Unfortunately, switching which card is used for the program does not fix the problem. Even changing the global default doesn’t fix it.

Too bad there’s no fix for 2019r1.1. It’s probably the first bug I’ve seen that doesn’t have a workaround.(other than just NOT using Windows 7, of course!)

Picture constructors come in a wide variety of forms and some include a bit depth parameter
The built in LR should be able to show you them

Do you know what picture formats cause this ?
Perhaps write a log message before the constructor to see if say a TIFF, PNG etc is causing this ?

“LR” ?

You’ve lost me. They are 512x512 .pngs.

Pretty sure the issue isn’t the images though, since these images are loaded into the main window and are shown fine without crashing. The crash happens when I open another (status) window in the app. If I never open that window, the app does not crash. The status window just has a couple of list boxes, no images.

Language Reference - sorry :slight_smile:

as for the images that is very odd

It seems we have an idea… with that, @Meestor_X could get a 32Bit build to work fine.

Let’s just say for now: It is yet another one of these “Direct2D Hardware Rendering issues with Xojo built apps.”

It’s unfortunate that this only works with 2019r2 (and newer):

In App.Open set the following environment variable: System.EnvironmentVariable("XOJO_D2D_SOFTWARE_RENDERING") = "True"

That would confirm it’s indeed yet another situation where Xojo’s “Direct2D Hardware Rendering” is not working as expected.

Another suspect usually is the Listbox, in combination with a ScreenScaling of something that could produce an uneven number. E.g.: scaling 125%; dynamic Listbox.Column.Width’s (using % and/or *).
Workaround for that: do compute the width’s yourself, so that (Scaling respected) the end-result is always a “full pixel width” for each Listbox.Column.

I think the “too large an image” issue may be a red herring.

feedback://showreport?report_id=54979
feedback://showreport?report_id=61981