With the new update to lwjgl 3 the class Display does not exists, i've searched everywhere but i can't find anything on how to put all my lwjgl app in a jpanel or in a canvas or anything like. I already thought to use an opengl gui like twl but it would make all more difficult and i don't need it, so my question is how to put the lwjgl app in a jpanel or in a canvas.
Thanks, it would save my life.
Unfortunately, there currently isn't any support for using LWJGL3 with Swing. Support for more windowing systems is in the roadmap, but it isn't clear whether it will be implemented at all.
From the roadmap:
Multiple windowing system implementations.
[✓] GLFW
LWJGL 2 compatible
[?] AWT/Canvas
[?][.x] JavaFX
One lesson learned from LWJGL 2 is that it's very hard for a windowing system to keep everyone happy. There was always that one feature missing. For 3, the plan is to support a few different windowing system back-ends and possibly an "official" API similar to the current one, with an unspecified implementation under the hood. This might sound like too important a part of LWJGL to be so open, but the fact is that the API surface is quite small. Even with no
abstraction layers, it's easy to move client code from one windowing system to another. Forcing a cross-platform and implementation-agnostic API to our users will soon hit us with the same issues we have in LWJGL 2. The only complete implementation we have for now, GLFW, is feature-packed and robust, but it's still early to commit to it. The plan is to explore many different options first and expose everything to users. They always know better.
[?]: Still under discussion. May change or is controversial and may not be implemented at all.
Related
I've been searching around quite a bit and haven't been able to find any details on how to accomplish what I'm attempting to do. I would like my Java application to "snap/mount/stick" to the top of the screen so that anything opened up after it (for example, power point) would only use the remaining space instead of the entire screen when maximized.
I'm not even sure if it is possible, but if it is could someone point me in the right direction?
Thanks.
You can't do that using standard Java features - only with some native code assistance which should be able to modify other applications behavior, so that they pack themselves into the remaining screen "space". But you will have to code that native part for each OS you want to support. And also you will have to call those native features from Java using JNI. And also some application might act unexpectedly when you will try to modify their size.
Anyway, its a bad idea to do such a "feature" in your Java application - you will have a lot of headache supporting it in future.
Colleagues of mine are using Java3D for visualizing results of finite element simulations. The problem is that Java3D seems to be somehow dead, and it is a pain on OSX. This is one of the reasons we are looking for alternatives.
Quite a lot of work has gone into our current implementation based on Java3D, so the question is how much effort it would be to move away from Java3D.
JOGL is one option, but looks like a lot of work.
Has anyone suggestions for alternatives? Any experiences with such a migration?
JOGL provides a direct access to OpenGL functions. These functions are mostly low level draw functions, and you have to deal with the 'state machine' nature of OpenGL while you are programming.
Java3D abstracts this state machine. It allows you to define a tree of graphic objects, placed in a virtual scene, and rendered by a camera. The manipulation of these graphic objects is easier with such a tree structure. Then, it's up to Java3D to walk through this tree and call the OpenGL drawing functions.
This kind of library is called a scenegraph. There are many scenegraph libraries in java, some are implemented on top of JOGL. I don't have a list, but this keyword will help you in your research.
In our project, we tried 3 or 4 different libraries, but no one filled all our requirements. We ended writing our own scenegraph library (on top of JOGL).
jMonkeyEngine, Ardor3D, jPCT or Xith3D are much better options these days.
JOGL is indeed a good option. However, it's simply a wrapper library for OpenGL. That means you'll still have to do a lot of the legwork yourself. If you're comfortable with that and it suits your needs, it's not actually all that difficult. But it might be a bit time consuming and not knowing your current code-base I don't know how easy the transfer is.
You could however go for an engine which might use JOGL. Something like JMonkey Engine to purely name an example. If you look, you'll surely find some others. Have a look at those, their ease of use and their functionality to see what best suits you. They probably won't take all the work away from you, but they might make it a bit easier.
See also this Java 3D forum thread : Java3D viability questions... https://forums.oracle.com/forums/thread.jspa?threadID=2150209&tstart=15
August, InteractiveMesh
I use JOGL 2.0 (which is a low level Java binding for the OpenGL (and OpenGL-ES) API. I have recently helped someone to revive Java3D. Now, it relies only on JOGL 2.0 and it works better, especially on Mac OS X. You can find the source code here:
https://github.com/hharrison/java3d-core
Let's have fun. It is actively maintained anew ;)
P.S: I wrote a detailed article to explain how to use the very latest version of Java3D (1.6) here.
I'm looking for a 2D scene graph library for building GUI applications. It should be fast, using Java2D and be compatible with Swing (embeddable in a Swing app and also display Swing components). Support for animations is a plus.
Do you have any experience with some of the libraries?
Are there any libraries that I have missed?
I have to add that I'm not totally offended by a Scala library.
Project Scene Graph
seems reasonably fast
only GPL (no LGPL)
supports animations
abandoned 2 years ago
as former part of JavaFX it's a Sun product
G
dunno whether it's fast
LGPL
no animations
last version Dec 09
Piccolo2D
for "zoomable user interfaces"
looks like an academic project
google code project with high activity
BSD licence
dunno if it's fast
dunno if it does animations
Pulpcore
is a game library
is targeted at applet deployment (using it as application is hacky)
very fast
supports animations
no development for 2-3 years
probably no Swing support at all
jTem
part of a bigger project (at first glance)
freeBSD license
no animation support
looks very minimal
Amino is another one created by Joshua Marinacci. It's very new, but has some interesting features such as CSS skinning, 2D or 3D backends. I am also very much intrigued about its use of an event bus rather than listeners, as that is quite in line with the Scala+Actor stuff I am working on at the moment.
That said, I haven't played with it (yet), so I don't know how good it is.
http://leonardosketch.org/amino
Piccolo2D, "academic work" or not, is well written. It's somewhat limited but does what it promises (a zoom-able graph) and does it fast. It can be used for at least basic animations such as moving, resizing, color transitions, etc but more can be done as it allows "normal drawing" as well. Has pretty extensive support for events for customization (here the "UI aspect" really shines).
It might be good just to try a few with "mocked" up scene to test for performance/features if this is really believed to be an issue. Piccolo is flexible enough to allow manual management if needed -- e.g. at different zooms display less and/or aggregate objects.
Happy coding.
I've been developing in Java Swing for a while now, and I'm starting to feel that Swing-based desktop applications are feeling a little stale and are tedious to develop.
I'm seeing new applications that look very sleek and modern, like TweetDeck and Synthesia (a piano game). Despite the wisdom in Haase & Guy's "Filthy Rich Clients," I imagine that writing applications like these in Swing would be quite a chore.
Presuming that desktop applications won't totally disappear within the next 5 years (or that the division between the web and the desktop will become seamless), what UI languages and technologies should front-end developers be exploring to keep current? What's the next big thing?
Microsoft's WPF is probably one of the newest, coolest technologies out there.
It allows you to make much better looking GUIs.
You should also look into some of Microsoft's Expression products. They let you put that extra flare into your GUIs.
I'm not sure there's "the next big thing" in desktop UI development. If anything, "the next big thing" is a multi-touch based interface ala popular tablets and smartphones. Given that, I think it might be smart to learn how to create multitouch UIs by downloading a sdk for a mobile phone or tablet that supports multitouch.
If you like Swing, Take a look at Google GWT.
It is like Swing for the Web, well almost.
There will always be a need for OpenGL/Direct3D developers, but that might be further down than you're talking about.
On the Windows side WPF and Windows Forms are available.
On the Mac/iOS Cocoa is the way to go.
On Linux there's a few options such as GTK or QT.
You might just want to bite the bullet and learn some HTML5/JavaScript though. I doubt that's going to go away any time soon.
I'd suggest looking into Flex. It's much more interesting to develop than Swing and b/c it's Flash it can run in a browser or on a desktop.
Java still works fine. You simply replace standard controls with images and use image states to change the look on mouse overs and clicks.
I would also suggest WPF as another UI framework to get under your belt, because it does afford some pretty powerful UIs in desktop applications (and most of what can be one in WPF is translatable to Silverlight for webapps).
On the flipside, instead of looking for the next new UI language or technology, I think you may be better served looking at UI from a usability standpoint, and tracking the trends currently making waves.
As an example, one of the paradigm shift I'm seeing in UI development (mostly on the web) is the switch to making important things bigger and less important things smaller - including yes/no buttons in a dialog. I'm still warming up to this idea because it flies in the face of a consistent button look to show users their options.
Instead of providing options in a world today where we are constantly making decisions, the goal of this newer UI look is to breadcrumb the happy path. If the user decides they want to do something different, they can, but the UI is going to make the user put in a little effort and read the fine print.
Another example is flash-highlighting a recent change a person has made (SO does this, but I forget the term used to describe this effect) when coming onto a website.
Lastly, and this is one of my favorites, the shift from an administrative/user view (also mostly in the webapp sphere), to an ad-hoc WYSIWYG editor...Flickr is a prime example of this, where you can change captions on a picture by clicking on the current caption and editing it inline, without the need to go to a separate admin view to edit these values.
Is anyone else seeing trends like these that are interesting and new?
You've been programming in Swing for a while and you only just started feeling it looks outdated? :)
Swing looks like crap, no matter what look-and-feel tricks folks do for it. It actually put vendors of Swing-based desktop apps like ourselves at a disadvantage because of how shiny and pretty WPF stuff looks.
If you want to stay in the Java realm, I encourage you to try out SWT and JFace. You don't need Eclipse for it. But it's a much better looking system with a much nicer API.
If you want to go for attractive, WPF is your friend. You're limited to Windows and can't use Java (both showstoppers for me), but you can't ignore the aesthetics benefits of that SDK because it is so tightly bound to recent versions of Windows.
I think the point of the book you mention, and most of the answers here, are that most languages give you the tools, (or enough rope to hang yourself ;) to throw out the basic ugly controls of ANY OS you are on, and paint whatever user experience you want to. Yes it is tedious to skin or otherwise manually take over the visual representation of the controls in a UI, but if that's whats important to you, then you'll do it, and possibly be rewarded for it. Or castigated for breaking the "platform UI standards".
I'm looking into technologies for a new embedded product that has a 1 ghz via processor, and a via s3 graphics chip. So far the target platform is Linux, but would like the option to move it over to a windows based platform.
The application would consist of widgets like buttons, graphs, and numeric/text displays. More importantly, the app would contain animating objects, such as fans constantly rotating.
Qt seemed like a good choice because it is cross-platform and has a nice API for a bunch of widgets and an animation framework.
However, this animation framework uses the CPU quite heavily. The target CPU usage for rendering the UI is 40%. Rotating 25 objects with an image uses about 90% CPU.
The thought is to use opengl to animate the objects and take that heavy load off the CPU.
My question is, if Qt the best choice for something like this? Should I be looking more heavily into something like Java 2D?
OpenGL could give you a performance boost:
Qt for Embedded Linux and OpenGL
Or maybe you need a better graphics driver (I don't know if your graphics chip is supported out of the box by Qt Embedded):
Adding an Accelerated Graphics Driver to Qt for Embedded Linux
As far as I recall, Qt's animation framework can be used for continuous animation, but probably isn't the best choice for such. I think it was more designed for transient animations, like sliding a widget around, or growing/shrinking things. I would look into either using OpenGL or possibly QGraphicsView, which allows you to do a more direct sort of drawing.
Additionally, if you look around, you should be able to find instructions for telling Qt to use OpenGL or OpenGL ES as the back-end for the rendering system, which shoud reduce some of the hit to your processor (assuming you haven't already done so).
You need to profile your application to really find out what is wrong there. For example, a fixed shape but continuously rotating graphics item can benefit a lot from item coordinate cache (see QGraphicsItem::setCacheMode). Likewise, fixed images should be cached and kept as long as possible as pixmaps. Color depth may also play an important role. Complex path-based graphics items should be simplified as much as possible.
In short, there are tons of reasons why graphics performance is bad. Without elaborating them and attack them one by one, moving into OpenGL will not really solve the problem. It might accelerate the frame-per-second (due to the obvious advantage of shifting some responsibilities to the graphics hardware), but this is a near-term advantage and quickly diminish in the long-term if the real problem is not uncovered.
Qt's primary selling point is that it's a cross-platform GUI toolkit, which is a nice feature but one that Java has already. You may prefer Qt's version, and many people do, but don't use it just because it's cross-platform. This article shows that the Qt animation framework is not yet integrated into Qt.
If you can program in GL then JOGL is an obvious start point, but if you can't be aware that GL programming is not easy. You might also consider Java3D. Possibly what you want can be done in JavaFX.