Thomas has posted 2 posts at DZone. View Full User Profile

The JavaFX Scenegraph Dilemma

08.06.2009
| 10674 views |
  • submit to reddit
There is a problem with JavaFX when using it to render more complex scenes: the scene’s memory use increases and performance degrades as more and more nodes are added to the scene.

"A dilemma is a problem offering at least two solutions or possibilities, of which none are practically acceptable; one in this position has been traditionally described as "being on the horns of a dilemma", neither horn being comfortable; or "being between a rock and a hard place", since both objects or metaphorical choices being rough." - Wikipedia

As an application designer developing a complex graphic solution (equivalent to an electronic circuit schematic diagram with hundred of symbols), I looked forward to using JavaFX, provided that it actually had the right stuff to meet the needs of my application. Presently, after having learnt much about JavaFX and Java 2D, hitting roadblocks and making seemingly endless design compromises, I remain stilted with the limitations inherent in JavaFX for realizing my graphic requirements.

I’ve chosen to write this post to bring this problem to light and to create the opportunity to discuss possible solutions in an open forum.

Java’s Graphic Evolution

Java 1.2 introduced the Java 2D API. This immediate mode API allows code to render graphics immediately via graphics context method calls. With a bit of work, some truly excellent graphic compositions can be created, as demonstrated in Vincent Hardy’s excellent Graphic Layer Framework book.

Competing against immediate mode is the concept of a scenegraph and its retained mode approach to rendering graphics via nodes, which are built up into a data structure (model) called a scene, and rendered via Java 2D. Instead of rendering graphics immediately, rendering takes place via a scenegraph manager in response to various scenegraph changes.

One of Java’s earliest (if not the earliest) scenegraphs was Piccolo, developed at the University of Maryland. While developing F3 (JavaFX’s predecessor), Chris Oliver used Piccolo as the original scenegraph API. For unknown (possibly political or legal) reasons, Sun replaced Piccolo with the somewhat inferior (less optimized) Scenario API.

MVC Coupling Scenarios

Most application user interfaces fit into the basic model, view and controller pattern (MVC), and it is desirable to see and build a user interface in such a consistent, logical and loosely coupled way. Where this simple pattern loses its power is when the view becomes too tightly coupled with the model. This is the danger with a scenegraph; it is a model that is a view that also has controllers. A scenegraph packages the MVC pattern in a specific way, which is suitable for some things, but not for others. In other words, it assumes too many roles, making it unsuitable for more elaborate rendering tasks in the long run.

The primary purpose of a scenegraph in a given complex rendering is to be a graphical representation of the data objects in a model. The first thing to notice when using a scenegraph is that it requires you to create nodes, which extend data objects that your model may already have. For example, the electronic circuit aspects mentioned above may already be expressed and structured as objects, in their own efficient model. If, instead, the model is expressed with nodes in a scenegraph, it can quickly consume a lot of memory and can bog down performance (if there are a lot of them). For instance, an electronic circuit schematic representation with its many symbols requires very many nodes. It gets even worse when you may want to have alternative graphic representations of the same model. Really, what a scenegraph wants you to do is use its nodes as your model, but this does not always work, except for relevantly straightforward things.

As I was considering the disadvantages of coupling the MVC too tightly, it gradually dawned on me that I actually have my own ‘graph’ of objects in the model suited to my needs, which I had already created, and that the redundant, memory hungry and poor performance results of using a scenegraph are not worth it. So here I am now, in the heart of a dilemma, where a scenegraph seems like an excellent solution, but really is not because I already have an optimal model, and its many data objects and their variables would consume way to many nodes to render using a scenegraph.

Okay, this sucks—where do I go next for my rendering needs? Should I go back to using only Java 2D? Is the JavaFX scenegraph really that inappropriate for my application’s needs? These are some of the questions that tear me apart, giving me a beautiful nightmare somewhere in limbo between JavaFX and Java 2D, trying to keep the joy in having a great project that has no easy graphic solution. It’s the kind of situation where I really want and would expect JavaFX to be perfectly suited for my needs, but this is just not the case.

After living the nightmare long enough, it has become increasingly clear to me that it’s best to assume my own responsibilities for most of what the JavaFX scenegraph would do for me. This includes data structures, picking/hitting, and layout/collision detection duties, as well as all rendering using only Java 2D. On the bright side, my application will be fast, not suffer from memory bloat, and have no quasi-redundant tiers. Manipulating and maintaining my model will also be streamlined, and graphic representation has become just a chore to be delegated to some off to the side process. Furthermore, it’s easier to have multiple graphic representations of my singular model. Hey, maybe the fog of JavaFX is lifted off my eyes and I’m really onto something better now!

JavaFX Performance Issues

Besides my application having its own design needs, which is making JavaFX not as useful to work with as I had hoped, there has also been a growing consensus in the JavaFX community that JavaFX’s performance is not all it could be. Here are some of the things that have come up:

The blogs above propose different solutions: creating ImageViews instead of using many nodes, and a Lens solution for rubberstamping nodes in a highly efficient way, which may never be implemented in JavaFX (why was this not in from the start?). Besides these items, some blogs also point out benchmark tests that have been conducted, and which are usually concerned with scenegraph speed over scenegraph design.

Hybrid Design Options

For my own application, I’m beginning to see how JavaFX and Java 2D can each work to make it happen, but this is only due to solutions like the Painter’s Canvas. For the model, I use special arrays (JavaFX sequences will not suffice) that contain POJO’s as data members. My view is composed in layers, which are essentially JavaJeff’s Painter Canvas nodes that render the model directly to an offscreen image (this is done with Java 2D directly, not with JavaFX in a tiled fashion), which is bound to an ImageView node in the scenegraph.

My own hit system is used to know where on the ImageView node I am editing, with my controllers using temporary inplace JavaFX nodes while editing. Editing changes are wired to my model, which records the changes and updates the ImageView node again via the offscreen Java 2D rendering mechanism. Pretty straightforward, just not what I had expected to have to do now that JavaFX exists.

Scaling The Challenge

What motivated me to write this post is Chris Oliver’s post on Instancing, where he presented his research on the Lens solution. We may never see this excellent solution, and it is a shame that it is not part of the scenegraph already. I can understand how it is a real challenge for the JavaFX engineers to create a flexible scenegraph that can serve different usages, including UI controls, games, animations and demanding graphic scenes like mine that feature too many symbols to be feasibly done with standard nodes only.

Some of us are really trying to put JavaFX to worthwhile use. However, to succeed, we need a flexible, adaptable and scalable scenegraph. We also need more insight into how and where to use the combination of JavaFX and Java 2D because not everyone wants to build only video or twitter applications. We should also have an open-sourced scenegraph API, and know more about where JavaFX is heading in its subsequent versions, instead of having to work in the dark.

Always hopeful…yet discontented,

Thom the inventor

Published at DZone with permission of its author, Thomas Buhr.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Greg Brown replied on Thu, 2009/08/06 - 9:39am

Hi Thom,

Have you looked at Apache Pivot? It is an open-source platform that provides an alternative to JavaFX (or Swing) for building RIAs in Java. Like Swing, Pivot's rendering model (which is based on Java2D) is primarily immediate, but it also includes a retained mode drawing API. It might be appropriate for your needs:

http://incubator.apache.org/pivot/

(FYI, I don't mean for this to come across as spam - I just wanted to point it out in case you weren't aware of it.)

Greg

Sergey Surikov replied on Thu, 2009/08/06 - 10:24am

There is a problem with JavaFX when using it to render more complex scenes: the scene’s memory use increases and performance degrades as more and more nodes are added to the scene.

 

Wrong. I used JavaFX in real projects. Applications has complex rich  GUI and don't demand big amount of memory. May be you use JavaFX in wrong way.

Doug Holton replied on Thu, 2009/08/06 - 1:55pm

I think scenegraph is still GPL licensed, too.

 I know the piccolo developers struggled with similar issues - whether to have a heavyweight root node class with a lot of functionality for example.  They eventually switched over from Java2D to .NET for speed reasons.

 The other direction you can go is to use a game or 3d engine (jogl, lwjgl, etc.) for hardware-accelerated graphics.

Some applet graphics examples and frameworks I've seen also skip java2d and build directly on top of AWT, such as pulpcore:

 http://www.interactivepulp.com/pulpcore/

 or this circuit simulation

falstad.com/circuit

Thomas Buhr replied on Thu, 2009/08/06 - 2:23pm in response to: Greg Brown

Hi Greg,

Thanks for the link to Apache Pivot, I take a look at it. JavaFX does a lot of things well and represents a significate move to bring Java into the RIA space. What I want at this time is for JavaFX to become more robust and suitable for complex graphics involving many nodes. Toward this end it would be best if the JavaFX scenegraph API was open sourced as well.

Thom

Thomas Buhr replied on Thu, 2009/08/06 - 2:51pm in response to: Sergey Surikov

Hi Sergey,

Yes, JavaFX is doing better now in the GUI area and its new controls have come along way. My focus is rather on challenge of utilizing nodes for the content of an application, not the form/widget oriented features of a standard application. For instance, applications built with Piccolo often featured large network graphs containing many nodes and the application still had fast response. I have not seen this type of content implemented with JavaFX yet.

I'm interested in efficient management of many nodes within a scenegraph used for content. I'm not so interested in how many effects can be stacked onto a node or GUI only nodes. If you have found a technique to avoid excessive memory usage when using many nodes you may also be interested in sharing your insight.

Thom

 

Sergey Surikov replied on Thu, 2009/08/06 - 3:03pm in response to: Thomas Buhr

If you publish example with extensive memory using i can help you improve it.

Thomas Buhr replied on Thu, 2009/08/06 - 3:20pm in response to: Doug Holton

 Hi edtechdev,

Thanks for the information. Chris Oliver has already proved that there is a solution that eliminates much of the heavyweight node issues, see his Instancing blog. While Pulpcore looks good its still missing a lot of useful features, I'm still in favor of JavaFX evolving to all it can be.

I'm sure Sun has the resources to improve the speed and design of the scenegraph API, I just hope they care enought to do so. Instead of jumping over into completely different API's I'd rather like to hear more about how JavaFX and Java 2D can work together to overcome scenegraph performance and design issues.

Thom

Jonathan Giles replied on Thu, 2009/08/06 - 3:33pm

JavaFX performance improvements are very important to the JavaFX team, and they are actively working on it. There are things like the Prism project, which is a new graphics stack for JavaFX. You can see more about this topic (briefly) discussed on my blog.

I would say that you should determine your approach (Java2D, JavaFX, etc) based on your needs. Java2D is far more developed and performant, but requires you to have a better understanding of your approach, given it's an immediate mode approach. JavaFX is certainly interesting, and as newer releases come out you should get performance enhancements for your app 'for free'.

I would also suggest you actually look into the options you have - it seems like you're complaining about your options without actually cutting a bit of test code to see just how (un)performant your options are. This could quickly put you at ease.

Good luck,
Jonathan Giles

Thomas Buhr replied on Thu, 2009/08/06 - 4:45pm in response to: Sergey Surikov

Hi Sergey,

It would be great to see an example of the Lens node proposed by Chris Oliver in his Instancing blog. This however requires getting into the undocumented features of the scenegraph API. Presently there is the node cache attribute, but it is only a hint that may not be taken into account by the JavaFX runtime (at least not all of the time). Furthermore, it takes memory to maintain a cache.

I have already resorted to using Java 2D for rendering my model to offscreen buffers, this works but bypasses the JavaFX scenegraph. With JavaFX you would need to create several layer nodes, then populate them with thousands (I will need even more) of font and shape based nodes to see the performance issues for yourself. If the Lens solution could be added into the solution it might work. The Draw app from the Pro JavaFX book might be a good base to extend for this quick test.

To test this out see how well the scene pans, repaints and how fast nodes can be picked. Likely it will be easy to see that nodes will cause performance degredation, this is why the best actual working solution am in favor of is JavaJeff's Painter's Canvas. As a node subclass the Painter's Canvas has all the ablities of a node plus it can be used to rubberstamp font glyphs and shapes onto an image.

Thom

 

Thomas Buhr replied on Thu, 2009/08/06 - 5:17pm in response to: Jonathan Giles

Hi Jonathon,

I'm sure glad performance improvements are very important to the JavaFX team. I am in the midst of determining my approach based on my needs for a commerical application that competes with products in the market place now. I'm going to be putting a chunk of money into this development as well so need to have strong graphic foundations in place, there is no time to be wrong.

Certiainly surfacing and telling my development experience was not meant to be perceived as complaining. It just echoes the blogs we have all seen already, only as a commercial venture I'm serious about the unresolved issues that have been raised. All the test code I currently have and have seen has not yet helped my mind be at complete ease.

There is further testing being conducted here at our end and all the actual looking into our options is yielding the best solution possible. We continue to face the delimma and hope to gain further insight by comparing practical sagery between JavaFX developers.

 Thom

Jonathan Giles replied on Thu, 2009/08/06 - 5:28pm in response to: Thomas Buhr

I think it's quite simple: if you want performance now, and are wedded to the Java stack, then go the Java2D/Swing route. If you are interested in pushing boundaries and are still wedded to Java, then try out JavaFX.

If you're making a commercial application in the coming six months, I would recommend you just stick to Java2D and Swing. It's performant and pretty well complete. If you aren't intending to cut code for a year, you can either stick with Java2D/Swing, or take a punt with JavaFX.

Keep things simple.

-- Jonathan

Thomas Buhr replied on Thu, 2009/08/06 - 10:04pm in response to: Jonathan Giles

Hi Jonathan,

Thanks for reducing this whole blog down to your simple advice, I truly hoped it would lead to deeper revelations not the same old, same old. Why does it have to be Java 2D or JavaFX? Has no one else required a composite solution? Should we only make the things that are set by the limits of either one?

I guess with the scenegraph being a closed box and having a vague roadmap there is not much anyone can do but wait and see. Frankly, due to this state, I'm not wed to any language or API, my concern is greater; it is the accomplishment of something unique, beautiful and functional.

Partially building, partially mending,

Thom

Jonathan Giles replied on Fri, 2009/08/07 - 12:08am in response to: Thomas Buhr

I guess the reason why you don't get a mixture of both solutions is that they are inherently different. A composite solution would entail a combination of immediate and retained mode graphics, wouldn't it?

The JavaFX team have been very careful not to expose the Java2D API through JavaFX, as they do not want anyone to depend on it. This allows for them to subsequently bring in the prism graphics stack as I mentioned above.

Perhaps once prism is introduced the kind of functionality you're after might be exposed, but frankly I'm a little confused why you'd want both immediate and retained mode graphics?

Finally, it's possible to make very nice looking and performant applications in Swing and Java2D - I have done this a number of times. Nowadays I spend my time split between working in Swing/Java2D and playing with JavaFX.

Cheers,
Jonathan Giles

Thomas Buhr replied on Fri, 2009/08/07 - 5:59pm

Hi Jonathon,

JavaFX and Java 2D are different, one being high-level and other being more low-level. However, just because we have JavaFX does not mean we should now throw the baby out with the bath water. Myself, I'm finding plenty of reasons to keep Java 2D around, both in the scene design and memory management areas.

For instance, the symbols I am painting are complex combinations font glyphs, shapes and associations. In fact there are so many parts to these symbols that it does not make sense to make each of them a node, even if I could. If I have both JavaFX and Java 2D to work with then I can create a more limited set of top-level nodes and use Java 2D to render their constituent parts. The problem with this approach is that JavaFX nodes do not expose their paint method. JavaJeff's Painter's Canvas however fixes this nicely. You can go further than this and also just use a single Painter's Canvas to stamp out your whole scene as an image. All you need is a data model to feed it the information it needs to paint.

Also, some of the parts that make up my top-level nodes are always the same, just at different locations. Rubberstamping these parts from the same cookie cutter node would make sense and once again the Painter's Canvas makes this possible, due to its bridge to the Java 2D immediate mode.

These are my main cases for using both retained and immediate modes together and I'm sure there are many more. I see that JavaJeff has just released a new post that introduces textured paints to JavaFX. This makes textures and a new subtle type of animation available to JavaFX. The post is available at the following link:

JavaFX developers are definitely happy about the fact that they can use all the other Java API's from JavaFX as well. Its the same case here, developers like me are happy that we can use Java 2D for special painting tasks that are only possible via Java 2D. This ablity only serves to extend nodes to be even more powerful, providing the full power of Java graphics to the scenegraph.

May JavaFX prosper,

Thom

 

Jess Holle replied on Fri, 2009/08/07 - 8:09pm

Of course the FX team is working on a major rework of the pipeline, etc, for sometime around the end of the year, so I suspect this isn't the final state of affairs.

Thomas Buhr replied on Fri, 2009/08/07 - 8:46pm

 Hi Jess,

This sounds excellent, however the end of the year is way off in the blue yonder. If we could get a clearer roadmap from the Java FX team that would be notable progress indeed. A schedule is something my investors would really appreciate as well.

Thom

Jonathan Giles replied on Sat, 2009/08/08 - 12:10am in response to: Thomas Buhr

Thom,

If you have investors and plan to release in the next 18 months, then almost certainly you should be taking the path of least resistance (and also the path with the most proof of actually working), and just get started investigating Java2D/Swing.

Perhaps I'm not keeping score, but I forget why you're not all that keen on just doing what everyone else has done up to now and use Java2D? It's proven, performant, and once you build your necessary abstractions will be quick to develop in.

-- Jonathan

Andrew McVeigh replied on Sat, 2009/08/08 - 7:46am in response to: Doug Holton

They eventually switched over from Java2D to .NET for speed reasons.

Since when?  Piccolo is available for both platforms and the java one is quite a bit newer.

http://www.piccolo2d.org/download.html

I use the Piccolo precursor (Jazz) with Java every day on a project and find it more than fast enough even with thousands of nodes.

Andrew

Osvaldo Doederlein replied on Sat, 2009/08/08 - 8:46am

Important fix: you linked to a very old entry from my blog that analyzed the performance of JavaFX 1.0/1.1. That was much changed in JavaFX 1.2, and I reported my updated evaluation of JavaFX's scene graph in later blogs, like:

First look at JavaFX 1.2

First look at JavaFX 1.2, Part II

JavaFX Balls 2.2: Effects and more

IMHO, the scene graph is already very good for its intended purpose, and I expect Prism to secure for JavaFX one of the top positions among Java scene graph (it's already pretty close IMHO). Notice that JavaFX has the unique advantages that it can include native code for full HW acceleration without requiring security authorizations, plus JRE integration, e.g. priority fixing of AWT/Java2D issues that impact JavaFX, etc.

Of course a general-purpose Scene Graph will never be as efficient as direct mode rendering, or even specialized scenegraph dedicated to a specific game engine or other particular purpose. But Java2D will always be there if you prefer it.

Thomas Buhr replied on Sat, 2009/08/08 - 11:12am in response to: Jonathan Giles

Hi Jonathon,

Thanks for your excellent advice. We are already familar with Java2D and Swing and I can think of two major reasons why I find a RIA scenegraph desireable. The first is that Swing is extremely boring and 80's to me and the interface I have in mind requires ZUI, HUD and RIA. The second is that earlier starting with Piccolo I got hooked on all the built-in features of a scenegraph; node structures, picking, handlers, etc. I found it desirable to not have to do these things myself.

Now, I'm some what wiser and have returned to using the best tool for the job, which is Java 2D for the main content. However, with the right modularity I still want to be in position to layer on technolgies like JavaFX, which is perfect for the UI and other widget related aspects. My architecture has grown increasingly loosly coupled over time, because API's become extinct and new API's become the rage of the day. In light of such upheaval it is good to know that my application is solidly grounded in its basic premise and domain at last. Now, via architecture and modularity I still also want to leverage up coming API's like JavaFX.

Thom

 

Thomas Buhr replied on Sat, 2009/08/08 - 11:23am in response to: Andrew McVeigh

Hi Andrew,

I agree, Piccolo briefly moving over to .NET and it was not for speed reasons. I remember an interview between Ben Bederson and Sun where the benefits of Piccolo were being explained to Sun. There was some confusion at that time about Sun not being willing to support the Piccolo project so they ended up getting support from .NET. Therefore, Piccolo was developed for .NET. And then, so the story unfolds, Sun came back a few short years later with a brand new scenegraph. They did not support Piccolo but liked the idea after all.

Glad to hear that Piccolo is working so well for you.

Thom

Thomas Buhr replied on Sat, 2009/08/08 - 11:46am in response to: Osvaldo Doederlein

Hi Osvaldo,

Thanks for keeping your important benchmark tests up to date. I always read them with great interest and they do indicate that JavaFX is getting better performance wise. I too believe that JavaFX will only keep getting better (I'm glad Oracle likes it too!) and that it has a solid foundation.

The case I'm making is just that my scene content is very dense and would also require a lot of nested nodes. The solution is actually simple, expose the nodes paint method and allow Java 2D to be used as part of creating custom nodes. Its ludicrous to only have the option of creating custom nodes with more nodes, instead of just using immediate mode painting where it would suffice. The options and therefore the possiblities of how a scenegraph can be designed and used will accelerate as soon as the scenegraph gains this understanding.

Best regards,

Thom

Andy Leung replied on Tue, 2009/08/11 - 7:53am

Scenegraph is just a concept of data structure, not really tied to specific framework.  Java3D has been successfully implemented with scenegraph concept.  I've tried Java3D since version 1.1 and all I can say is it's amazing!

The idea of having scenegraph comparing to traditional rendering phases is to abstract the rendering and model change process.  In the end, the entire rendering process and model change process become streamlined.  Models (nodes) can be shared states.  Updating nodes can be multi-threaded too and this is the good thing.

It is not easy to build multi-threaded model change process in traditional rendering flow (in C++) since you  have to customize your own rendering phase and in most of the time you mix the rendering and model change process to shorten your development time.

However, Scenegraph rendering isolates them and standardized the rendering pipeline.  So now all you need is to initiate the rendering engine and let it runs, all you need to take care of is to update the model and that's all.

In the end I think JavaFX is in the right direction except that Sun should really take one step farther to make it better.

Thomas Buhr replied on Wed, 2009/08/12 - 12:03am in response to: Andy Leung

Hi hksduhksdu,

I agree that a scenegraph is a useful data structure, I had started applying them to my projects starting with Piccolo, which had far less performance issues, as Andrew McVeigh makes note of in the following blog:

 JavaFX has improved some what since then, see also:

Piccolo also allowed custom nodes to be created in multiple ways. One way was to override the nodes paint method and use Java 2D instead of using only more nodes to render the node. This is still missing from JavaFX.

Piccolo also had an alternate faster pipeline implementation called Agile2D, lately there has been talk of Prism for JavaFX which may serve the same purpose. Word has it that Prism will not use Java 2D to render the scenegraph. From this you can see that there is a lot up in the air with JavaFX, making it even more difficult to know where and how it may play a role in my project.

Thom

 

Matthew Hegarty replied on Wed, 2009/08/12 - 11:25am

Hi Thom

As others have said, you really cannot consider JavaFX at the moment for any serious application.  Aside from the performance issues, trying to write anything other than the most basic apps will show you how immature the platform is as you will doubtless hit numerous bugs of varying severity.  Although JavaFX is officially at 1.2, it's not close to 1.0 yet IMO.

To add to the issues, there doesn't seem to be a huge push on Sun's part to fix the defects; and as you point out, there is no clear roadmap for the future of the platform.

In scoping your application I'm sure you've looked at various options - what about Eclipse RCP?  I don't know much about your domain other than what you've hinted at, but RCP seems suited to more niche data-intensive apps:

http://eclipse.org/community/rcpcp.php

 Unfortunately, the options for UI customisation are rather limited, and the learning curve for writing RCP apps is steep.  Might be worth a look though.

 I've written some semi-serious stuff with JavaFX up to now, and I'm impressed with the language itself and the ease with which one can create graphical apps.  However, its immaturity is a frustration and I would say that we're some months away from a version stable enough for commercial apps.

"Always hopeful…yet discontented" - I think that is a good summary of my attitude to JavaFX as well!

 Matt

Thomas Buhr replied on Wed, 2009/08/12 - 11:40pm

Hi Matt,

I just got back from a strategic development session and we reached the same conclusion, that our progress is too cribbled by considering JavaFX at this time. Its time to get the show on the road and make some progress. The JavaFX language is all well but that would never be reason enough. I would have prefered an open source Scenario API without the JavaFX script aspect.

Thanks for the Eclipse RCP info, likely I will not use it because I want to have a powerful model, a fast view and a minimalist UI with a HUD look and feel that allows users to edit data directly in place. I see no need to give up screen real estate to buttons and other such controls.

Best regards,

Thom

Alan O'Leary replied on Sun, 2009/11/22 - 3:15pm

 

Also agree with above... Invested significant time into JavaFX but its 0.0.1.2 at the moment ...

@superstring .. Swing is powerful enough to get you interfaces like the following .. its just a pity its left hanging at the moment... http://revolucionlibrary.files.wordpress.com/2009/02/main1.png

softwarevisuali... replied on Wed, 2011/03/02 - 8:46pm in response to: Jonathan Giles

Please please please don't ask "why would you want that?" That's the one question that makes me cringe and get anxious that I'm going to be hamstrung by someone else's vision . I want that because there's something I want to do with it, that's why. It's wanted because people think of innovative ways to use technology if that technology is made accessible to them. Why would anyone outside of corporations or academia want a computer? Why would anyone need access to the internet? I want this so I can draw what I want the way I want when I want where I want for purposes that I can't forsee yet. Sorry if this sounded a bit harsh. Ha, you know what? You can edit posts once you've posted them. A side effect of this is that you can remove what you wrote after you wrote it. Which is why my post seems nonsensical in reply to the post I replied to. The part I was replying to is no longer there. Ha! So this post looks a little strange! Actually, someone asked of someone else "why would you want the scenegraph to do X". Thus my response. Ha! Who knew? You can rewrite history!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.