Arithmetic result exceeded 32 bits with large image.

[grokys]

I am trying to open a .png file with dimensions of 40,000x40,000 pixels in a 64-bit application using the WARP device, but I am getting the error

HRESULT_FROM_WIN32(ERROR_ARITHMETIC_OVERFLOW) : Arithmetic result exceeded 32 bits. 

This is thrown from CanvasDevice.cpp:476. Is this a limitation in Direct2D or in Win2D?

[shawnhar]

This appears to be a D2D limitation, although I haven't bottomed out on exactly where it is originating. When using a software device (CanvasDevice created using CanvasHardwareAcceleration.Off) I can load bitmaps up to 32767x32767 in size, but 32768 and above hit this error. Hardware GPU devices obviously have a lower limit, which depends on the D3D feature level of your GPU.

I'm curious what are you doing that requires such large images? I got quite bored even just waiting for one to save when I created it for a test just now :-)

[grokys]

I'm writing CAD software for designers of things such as carpets, who are starting to use larger and larger images to represent i.e. entire buildings. At the moment our applications can't handle more than around 16k well, which is approximately the largest size currently needed, but they keep requesting bigger and bigger and we're trying to future-proof for the next generation...

[shawnhar]

Cool project!

I found the root cause of where this error is originating inside D2D, and unfortunately it's not something we're going to be able to address in Win2D. The actual limit is not on either width or height, but that the total width * height * bytes per pixel needs to fit in 32 bits. So eg. 40,000 x 25,000 would be ok.

How bad is this limit for your scenario? Although the size of D2D bitmaps is limited, the underlying WIC image decoder can go larger, so it would be possible to decode pieces of a very large image into multiple separate bitmaps. That's not something Win2D makes easy today (it would require using COM WIC APIs or the Windows.Graphics.Imaging WinRT APIs to do the decode, then transferring the resulting data across to CanvasBitmap) but if it's important for your app I can help with the details of how to plumb these things up to each other. (may also be something we could streamline in Win2D in the future if we see broader demand)

[grokys]

Thanks for investigating! Do you have any idea if this limitation is likely to be lifted in a newer version of Direct2D? 32k images are likely to be enough for the moment, and I don't want to have to implement tiling if the limitation is likely to be removed. I understand you can't make promises about future versions, but a hint would be good enough for now. Especially considering that DirectX 11 GPUs already can handle 16k images...

[shawnhar]

I am following up with the D2D team to understand whether this limit is intentional or if it's something they might be interested in someday removing. For now, though, you should assume it'll stay this way for the foreseeable future.

Going larger than 32k per axis opens up some 'interesting' problems above and beyond the excessive memory usage and total image size that overflows DWORD range. For instance, this is about where texture coordinates start to experience floating point precision artifacts when doing subpixel computations during interpolation and filtering. So it may not be as simple as just removing whatever check is currently failing, even when using WARP as the rendering backend...

[shawnhar]

I'm closing this issue as we don't expect to make any changes in Win2D as a result of it. Thanks for the report and please let us know (feel free to reactivate) if the 32k limitation someday does become blocking for you.