locked
Why is FillGeometry with winding and large coordinates incorrectly filled in Direct2D? RRS feed

  • Question

  • Hi all

    I have a MFC program that use Direct2D to paint.
    The application is using SetTransform to manipulate a view that shows a model containing objects created with FillGeometry.
    When I zoom in I get horizontal and vertical lines in a shape that should have been filled.

    It feels very much like a Direct2D bug.

    I have made a post with pictures and code on Stackoverflow

    I am hoping that some of the experts in here can either confirm that this is a Direct2D bug or indicate if this is by design because of some limitation.

    Thank you very much of any help.
    Wednesday, May 8, 2019 7:06 AM

Answers

  • I would be willing to call this a GPU driver bug.

    My test application doesn't use MFC, so this means that I was able to initialise Direct3D11 manually. Direct3D11 using the reference device and the WARP device ended up having no problems with this code.

    This means that Direct2D itself is not doing anything wrong. Because the reference/WARP devices are also giving correct results, I would be surprised if this is also a Direct3D issue.

    It is only when you run it on hardware that it starts having problems, and then it is inconsistent, this alone gives serious driver related problem vibes.

    Annoyingly, you would have to try to contact someone on the Direct3D team to try to resolve this, and that would most likely result in you starting a support incident with Microsoft.

    Oh, and don't worry about the transparency, this was tested using one of the composition samples that I had been working on. Setting alpha to 1 for everything didn't change the output of the geometries shape.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Wednesday, May 8, 2019 10:49 AM

All replies

  • I tested in a C++/Win32 app and if I reduce :

    const float fOffset = 50000000;
    

    ( 5000000 for example )

    I don't get the lines.

    Wednesday, May 8, 2019 7:52 AM
  • I would be willing to call this a GPU driver bug.

    My test application doesn't use MFC, so this means that I was able to initialise Direct3D11 manually. Direct3D11 using the reference device and the WARP device ended up having no problems with this code.

    This means that Direct2D itself is not doing anything wrong. Because the reference/WARP devices are also giving correct results, I would be surprised if this is also a Direct3D issue.

    It is only when you run it on hardware that it starts having problems, and then it is inconsistent, this alone gives serious driver related problem vibes.

    Annoyingly, you would have to try to contact someone on the Direct3D team to try to resolve this, and that would most likely result in you starting a support incident with Microsoft.

    Oh, and don't worry about the transparency, this was tested using one of the composition samples that I had been working on. Setting alpha to 1 for everything didn't change the output of the geometries shape.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Wednesday, May 8, 2019 10:49 AM
  • Thanks for you answer.

    One thing that I do not understand is, if this is a GPU driver bug why is that not Nvidia / AMD that I need to contact? What is the relation between the Microsoft Direct3D team and the GPU driver ?

    Wednesday, May 8, 2019 2:18 PM
  • I like to hedge my bets since I'm not 100% sure that it is a driver bug. This is why I stated that I am willing to call it a driver bug, not certain it is one.

    There is also the fact that Microsoft could fully determine if this is a bug somewhere in Windows, and if it isn't, then will normally pass this on to the GPU driver vendors.

    You could contact the driver vendors individually if you want to, this is entirely up to you. But it is probably going to be a bit easier to get this resolved if you can get this confirmed by Microsoft.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Wednesday, May 8, 2019 3:13 PM