WindowSize should be allowed to be zero

[ZionPi]

In Library\Native.cs file ,there is a WindowSize method:

public static void WindowSize(int width, int height)
        {
            if (width <= 0) {
                throw new ArgumentOutOfRangeException("width");
            } else if (height <= 0) {
               throw new ArgumentOutOfRangeException("height");
            }

            if (!NativeMethods.TwWindowSize(width, height)) {
                throw new AntTweakBarException("TwWindowSize failed.");
            }
        }

According to this page,when dealing with With DXUT (DirectX SDK),call TwWindowSize(0, 0) will make the device to release resouces.That is exactly what I want when handling OnDeviceLost event.If zero is not allowed,resource management cannot be handled in another way as far as I know,resize operation will make the app crash.I have test in my SlimDX based app,it worked.
Just a bug report.

[TomCrypto]

Very good point. I have just tested with OpenGL too and it does not seem to pose an issue (the bars just disappear until a new size is given, so I suppose it releases some resources too). I see no problem with allowing a size of (0, 0).

How about this:

public static void WindowSize(int width, int height)
{
    if ((width == 0) && (height > 0)) {
        throw new ArgumentOutOfRangeException("width");
    } else if ((height == 0) && (width > 0)) {
        throw new ArgumentOutOfRangeException("height");
    }

    if (!NativeMethods.TwWindowSize(width, height)) {
        throw new AntTweakBarException("TwWindowSize failed.");
    }
}

So that (0, 0) is accepted to allow releasing ATB resources but invalid sizes like (0, 100) or (50, 0) are rejected. (I try to do as much error checking as I can on the C# side because the results of some AntTweakBar calls with invalid parameters can be quite unpredictable).

If it works properly it might also be worth adding a ReleaseResources method or similar to the context class that calls WindowSize with a size of zero, as a convenience function and to document this behaviour in the code.

[ZionPi]

Since there is no event like OnDeviceLost and OnDeviceReset for device itself in SlimDX.Those events are indirectly handled by the device's host Control events like Resize and OnSizeChanged(or some others?).It will be nice to have a Release and Reset methods in Context , imho.

[TomCrypto]

How would the Reset method work? Should the context remember its window size and then reset the same size as before a Release call? (I don't think AntTweakBar has a function to obtain the size it currently believes the window to be, but it's okay to save it in the context I think).

Or do you mean aliasing Reset to HandleResize so that they do the same thing but calling Reset is more self-documenting after calling Release?

[ZionPi]

Context is much like the Effect class in SlimDX which should react properly when device state has changed(lost,reset) to avoid memory leak.For that end,Effect class has provided OnLostDevice()(Called when the Direct3D device has been lost) and OnResetDevice() (Called when the Direct3D device has been reset.) accordindly.You can refer to Effect class documentation here.

[TomCrypto]

If I understand correctly the OnResetDevice and OnLostDevice methods are originally called from the window which detects when the device is lost, and then propagate themselves to every graphics object in the application by recursively calling the OnLostDevice or OnResetDevice methods of any resources they own. If so, that will be perfect, and I will add these methods to the context so that it can properly handle device loss and reset (provided the user actually calls them, of course).

As we have seen the Draw method is already a no-op when the window size is (0, 0), which I think is the correct behaviour. Should the HandleResize method fail if called between lost and reset? I don't think it poses a problem if it doesn't but perhaps it would be better in terms of correctness.

[TomCrypto]

How's that?

[ZionPi]

Your understand is OK.In practice,HandleResize will not happen between them.It is the resize action that leads to device lost and so on(more detail in this page).I don't have much knowledge on how OpenGL stuff would handle this.

[TomCrypto]

I believe device lost/reset is exclusive to D3D9 (it has been removed in D3D10+, and I don't know anything similar in OpenGL). That said I gave the methods generic enough names to be possibly useful with any graphics API. Let me know if there is anything missing or that could be improved.