RunTime error DrawableD2D

And one more today !!! Windows 7 64 bits, running on a dell with 16 go Ram.

Any idea where we could find a workaround , please ?

THis is going to be a very big problem here.

What is the bitmap image size ? etc. ?

Not enough memory. User must add more memory to the system. A 4Gb computer can’t handle your job. Large images must be handled and released from the memory. Some paging system must be done.

This Feedback still open without a Xojo “feedback” <https://xojo.com/issue/46551>

When will Microsoft stop support for this OS ?

It looks like Windows 7 end of life is in 2020.

Window 7

the image size is (1700, 2210 ) [width, height ]

The feedback pointed out that it is not related to Win7 because the same happens under Win10.

Interesting that the report says that same routine using the old GDI+ does the job.

First case happened on an Old 2013 Dell with only 4Go, running Windows 10 64 bits. I agree this is not very cute.

Today it’s a recent Dell with 16 Go Ram and Windows 7 64 bits…

I "m beginnig to think the trouble is linked with Dell Computers…

Yes , I saw this and followed it.

yep, I didn’t have any trouble using an older Xojo version… It happened with Xojo 2019r1.1, while building 64 bits versions… And I can confirm that previous version ( 32 bts, Xojo 2017 r2.1 ) is runnig at the moment on the machine. So, clearly, this is caused by Xojo framework version…

As far as I remember, Xojo has “fixed” the flickering on TargetWindows with 2018r1.
And this resulted in that: <https://xojo.com/issue/54421>. And I suspect this is the cause of your issue(s).
The Xojo Framework does an insanely bad job regarding memory management when it comes to Pictures.
When you’d expect at max 100MB memory usage, Xojo built Windows apps might easily need > 3GB.

It’s basically a “(c runtime) out of memory” exception (when trying to allocate memory for the Picture/Graphics), which just crashes your app hard. And not being able to catch these kind of Exceptions but crashing hard has been like this since reported in 2009: <https://xojo.com/issue/12072>

That’s why it’s my suspiction that it all boils down to this insane memory usage that Pictures need in the XojoFramework (TargetWindows). While the “end picture (the one you’re drawing)” might not be the issue, it’s maybe the “source resources/Pictures/Graphics” you need/have in memory to draw into your newly created Picture.

While you can’t fix anything… you can try to see if the Workaround mentioned in <https://xojo.com/issue/54421> is an option in your project. Basically:

  • don’t store any (big) Pictures in Variables (Arrays, Properties, …), especially not if you’ve ever used them. They will have such a big “cache” needing a huge amount of memory.
  • if you need to store Pictures temporarily: do draw them as a New Picture instance (or: see below)
  • never-ever use a Picture with references that stay in memory to draw. Always get it into a new Picture instance, then draw, then dispose of it (along with it’s cache that the XojoFramework has put on to of it)

I know… that workaround is so silly… But it’s the only way our application(s) don’t crash like this on Windows. In our case it will (well: used to) crash when loading 30 Pictures (original size/resolution of a usual camera picture) in memory, then drawing them one-after-another (scaled down, e.g. for printing purpose).

First: we store them as a “buffer picture” (new instance!):

bufferPicture = New Picture(sourcePicture.Width, sourcePicture.Height, Array(sourcePicture)) bufferPicture = sourcePicture.HorizontalResolution bufferPicture = sourcePicture.VerticalResolution

That way you we can store these 30-50 Picture without an excessive memory usage.
When one of these buffered Pictures needs to get drawn: get them out of the Buffer (as a new instance!):

tempPicture = bufferPicture.IndexedImage(0) tempPicture.HorizontalResolution = ___ 'depending on XojoVersion you need to assign that again tempPicture.VerticalResolution = ___ 'depending on XojoVersion you need to assign that again
Then draw the tempPicture, and get rid of it asap. Never have several tempPictures in memory.

So the “trick” is that only the single tempPicture instance get this XojoFramework cache. Never-ever an instance that is stored somewhere else.

I hope you’re “just” affected by this enormous memory usage, too. And in the best case, you can think of a workaround that works in your situation/application - for now.