Anyway, our current implementation can be improved. For example:

Detect cases where the opacity is not needed and generate a warning in the log or even being smart and try to carry the opacity to the brush of the internal node. I would say this will eliminate a very high percentage of offscreen uses.
If there is not enough space in the offscreen texture instead of giving an error we could render the node without opacity with straight forward render. Although this will render the xaml incorrectly.

That's sounds good solution for eliminating the runtime crashes.
If all GUI states are know you can add an automatic test on the Build Tool that will try to render each element with all available states and compute the needed Offscreen space... not sure if it's possible.

In my case I've got the runtime crashes when I dynamically allocated Buttons and placed an Image in each of them. When I replaced the control to use simple ListBoxItem with TextBlocks and only one Image displayed at a time the errors were gone.

Another alternative is to use application callback. The rendering system will issue a callback that requests to allocate texture resources. This way the application can decide whether or not to allocate additional GPU memory for the UI layer.

If all GUI states are know you can add an automatic test on the Build Tool that will try to render each element with all available states and compute the needed Offscreen space... not sure if it's possible..

The problem is that at build time there is not enough context to calculate that information. For example, the .xaml you are building could be inserted inside a container with a dictionary that alter your representation.

Even if we could calculate that information for xaml, that would not solve the problem because at runtime we don't know how many xaml are going to be used in your application.

In my case I've got the runtime crashes when I dynamically allocated Buttons and placed an Image in each of them. When I replaced the control to use simple ListBoxItem with TextBlocks and only one Image displayed at a time the errors were gone..

What values did you have to set to offscreen sizes to avoid errors?

Another alternative is to use application callback. The rendering system will issue a callback that requests to allocate texture resources. This way the application can decide whether or not to allocate additional GPU memory for the UI layer.

Yes, that is an option we have in mind. At init time, the user passes us the offscreen surfaces (we dont create them internally). Problem with this approach is that the client code is more complex (you have to deal with multiplatform issues to create the render targets).

Anyway, allocating render targets in the middle of the execution is always a bad idea. It was our first approach in the beta and the results were not good.

Thanks for your suggestions!

What values did you have to set to offscreen sizes to avoid errors?

I had to use 1,8 to avoid Errors. My target size was set to 1280x720.

Yes, that is an option we have in mind. At init time, the user passes us the offscreen surfaces (we dont create them internally). Problem with this approach is that the client code is more complex (you have to deal with multiplatform issues to create the render targets).

I didn't mean that the user will pass the surfaces implementation at all, just that your engine will ask if the user allows to allocate certain amount of memory for the offscreen surfaces. It will be up to the application code to decide if it allows allocation to occur in the called context (initialization, runtime, etc..) and other resource management consideration it might have.

I have this problem too now with the provided examples in the Unity Editor on Mac OS X and on device builds.

I can for example just load up the Buttons.xaml with at the top and I get the out of memory error just after clicking the buttons for a while.

I can crash the ControlGallery example by switching back and forth between the examples in the first group where the image texture modes are shown. To me it feels as if there is a resource management problem and texture memory is being leaked and not properly cleaned up.

Using 1.1.7.4810-TrialRT.

If the error message says something like: "Offscreen atlas texture is full. Can't find space for 100x20 rectangle.", this is not a memory problem but a limitation of our opacity group implementation. We use a fixed size texture for opacity groups generation to avoid undesired stutters during runtime because of big texture creation. You can tweak the size of that texture in the NoesisGUIPanel component, by changing the Offscreen width and height to higher values. Let me know if this fixes your crashes with the ControlGallery sample.

I can crash the ControlGallery example by switching back and forth between the examples in the first group where the image texture modes are shown.

I was able to reproduce the error. If you select the NoesisGUIPanel component from the main camera in the ControlGallery sample, and set the Offscreen height to 1.25, then the error doesn't show again. We will fix it for the next release. Thanks for your feedback.

This exception still happens with the Reflections demo when you switch to it in the ControlGallery sample scene. Works OK in Kaxaml though.

I also get the exception occasionally with scrollviews, despite 100% opacity.

Yes, very rare I'm also see crash because of this issue. It would be great if the NoesisGUI can avoid crush in such cases (by auto increasing offscreen buffer + warning about it to console).

I can reproduce it with the Noesis style and the Unity panel layout shown below. If I move the separator between Scene/Game and Console more to the right then the exception does not occur.

This happens with default Offscreen Width 2 and Offscreen Height 1 or 1.25. Higher values of the Offscreen Width will prevent the exception.

This is a screenshot of just before the exception ("Can't find space for 617x52 rectangle") is thrown:

http://imgur.com/3DK4CIS

In this screenshot the separator is placed just enough to the right to prevent an exception. Note the lack of the vertical scrollbar compared to above makes no difference. Exception will still happen if the separator is moved a few pixels to the left.

http://imgur.com/GTsVp5v

Edit: It even happens in fullscreen mode. If I change offscreen width and height, the multiple must not exceed 4 or performance will take a big hit.