The original is intended for Runtime project.

While investigating http://javafx-jira.kenai.com/browse/RT-17345 I came to the conclusion that the current ownership of graphics context is wrong.

The reason we hit the issue in RT-17345 is because currently Glass owns the on-screen graphics context and requires the client to lock the View if it wants to use the context - ex: for releasing its resources. However, if the client happens to destroy the View then it can no longer use the graphics context.

We could require the client to change so that it releases any resource before closing the View, however, that should not be required if the graphics context was to be owned by the Glass client (ie. Prism)

If that were the case, then the client can release View at any time, and still be free to use its graphics context for releasing any resources. This is a much nicer scenario.

The changes related to this need to be done both in Glass and Glass client (ie. Prism)

For Glass we need to change the View to take the graphics context in the constructor.

For Prism we need to change the code, so that it creates the graphics context and then passes it to Glass when creating the View.