I want to catch the system's standard output, that is all that we can see at the monitor, from 0,0 coordinates to x,y. I've tried to make 50 screen capture per second with the Robot.createScreenCapture(Rectangle rectangle)) method, but it use a lot of memory and CPU. Instead, If I could catch the standard output and reproduce it in a video player (for example) I think that it should use less memory and cpu. Can anyone point me in the direction?
Recording the screen is a very OS environment specific task. On Linux one would, for example, do screen capture by talking to the X server directly using XLib or similar library.
If you are lucky someone has created a library in Java which abstracts this work (Like the Robot class), but if you can't find such a library then you will have to do the implementation for each platform yourself.
Unfortunately you would probably have to do some work in another language than Java since there might not exist Java bindings for the OS specific calls that you would have to make.
A good starting point would be to look at an existing project. For Linux this could be RecordMyDesktop:
http://recordmydesktop.sourceforge.net/development.php
For Windows you could look at: http://taksi.sourceforge.net/
So to sum things up: Java might not be right "hammer" for the task in question.
Related
I would like to read RPMs of the (Windows 7) system fans in Java (like, for example, the application SpeedFan does) to use them for an Arduino based LED project (make fan appear slowly moving by PWMing leds). However, the system has a fan controller so I have to read the rpm continuously. Found nothing after Googling, only a tutorial of how to read the RPM directly from the yellow wire on an Arduino (however, this is not a solution, because I wouldn't like to do hardware modifications on the system itself). Anyone got ideas?
I think best solution is using JNI or JNA. With it you can use all WinAPI functions, as a result you can get all info what you want. If in the future you'll want read another system info you already have base structure, it's good scalability.
Also you can try find third-party program and get needed info from it, but it's bad idea because maybe in the future when you'll setup another version your third-party program maybe will not work.
Does X-Windows have to be installed on a Linux-box in order for Java to display fullscreen graphics?
Well "fullscreen graphics" is a bit vague.
Anyway, apparently there is a an effort ongoing to access the framebuffer from Java: Framebuffer Toolkit.
The objective of this project is to produce a body of code which is
a lightweight framebuffer-based peer implementation for AWT and Swing.
The goal of this code is to remove the dependency on X or
other graphics layers such that graphics can be redirected to
a framebuffer (e.g. a raw buffer, VNC, etc.). This example
implementation will prefer pure-Java solutions, with public
extension points available to enter native resources as necessary.
See Project proposal: fbtoolkit.
Other answerers appear to assume that "full screen graphics in Java" necessarily means "a working implementation of AWT". This is, of course, not necessarily true, as it is perfectly possible (some would even say desirable) to use Java without AWT.
Cairo is a 2D graphics rendering library that can be used from Java, and can also be used without X11. It looks at first glance as though it should be possible to configure it for this scenario. You'll need to configure it to use OpenGL rendering, and provide a suitable non-X11 OpenGL implementation (e.g. MesaGL with the 'fbdev' device driver).
SDLJava is a Java port of the popular C SDL game development library. This also should be able to do what you ask for, although it doesn't seem to have been updated since 2005 so if you have any problems with it support may not be forthcoming.
As an alternative, you could always use some fairly simple C code to open and configure the framebuffer, and then use JNI to return the memory-mapped framebuffer as a direct-mode ByteBuffer, so you can draw to it directly.
To really display something graphical on the screen, yes. Bud there is a headless version of the JRE for just running it. You won't see any graphical output, but it will run.
Alternatively, you can log in remotely and use X forwarding to run the java code on the server but let the client handle displaying graphics.
On an embedded device, such as a Raspberry Pi, if you don't want to go through full X11 with standard Java AWT + Swing, then this https://github.com/ttww/JavaFrameBuffer project to write straight into the frame buffer seems interesting.
An alternative may be to use e.g. SWT on GTK, or Qt Jambi, to write into the Frame Buffer (both GTK and QT can directly use a FB without X11).
I'm interested in knowing how can my Java program listen to the Print event generated by the underlying OS. As my project is based on Java, the Print job event listener should not be platform depended.
To be more specific my program will be running on the background and should be notified of the print job if a user is trying to print pages from MS Word (for an example). The event should notify not only the print job being started but also other details such as No. of pages, the document location etc (if that's possible). A link to complete tutorial or some snippets would be much appreciated. Thanks!
We are a C++ and Java shop. I have written code that does pretty much what you are asking for. It was written in C++ for Win32 (and was a right bugger to get correct - this is one of the least well documented areas of the Win32 API - and different printers send different event streams, so it can be really tough to develop robust print queue handling).
If someone has created a JNI library for doing this stuff (unlikely), there is no way it will be cross-platform. The effort involved would be enormous (different OSes handle print queues and notifications in completely different ways).
My recommendation would be to brush up on your Win32 programming (with C/C++). Once you have things working there, if you absolutely must have them interact with your Java app, you can use JNI to wrap it.
Here's MSDN articles on printer change notification monitoring (you'll have to call OpenPrinter first - but the next call is FindFirstPrinterChangeNotification): http://msdn.microsoft.com/en-us/library/dd162722(VS.85).aspx
If you are trying to support *nix and mac as well, you'll need to dig for those separately. Good luck.
I'm looking for a way to know in a Java application (without JNI - it's a multi-platform application) can detect if the screen is locked.
For information... our application records time while a user is working - we want it to automatically stop recording when the screen is locked instead of the user having to do so explicitly.
I don't think there is an API for that or even a way to do it all. Parsing screenshots generated by java.awt.Robot is neither platform- nor version- or even configuration-independant, and in general, I don't think "screen is locked" is a well-enough defined concept to be used in this sense - on Linux, there can be more than just one "screen" (X server), you can switch to console terminals, you can have applications running one (or more) machines display their GUIs on another machine over the network...
I confirm there seems to be no Java API to detect a screen lock status.
Spark developer gave it a try in 2006 (like this thread shows), but without giving out any details on the specific of the implementation.
However, it is likely it involved JNI and native call to functions like WTSQuerySessionInformation (To detect if disconnected use WTSQuerySessionInformation(NULL, WTS_CURRENT_SESSION, WTSConnectState) and look for WTSDisconnected).
So, as Michael pointed out, there is no "multi-platform" universal answer (to the best of my knowledge).
I am trying to make an application in which one component captures the screen of the user (for screen casting). I am aware that there are two options to achieve the same using a Java applet (please correct me if I am wrong). First is to use the java applet to take screen shots continuously and convert it into a video and upload it as a video file. And second is to create a java vnc server and record it as a .fbs file and play it using a player like: http://www.wizhelp.com/flashlight-vnc/index.html
I would like to know the best solution in terms of video quality, file size, cross-platform compatibility (windows and mac), firewall problems and finally ease of implementation.
I am very new to Java. Please tell me whats the best solution for my problem. Also, is it easy enough for me to program it on my own or should I get it developed via a freelancer. I have tons of programming experience (5+ years in LAMP) but none in Java.
Thank you very much.
I agree that this is pretty hard. I implemented those two solutions (VNC and onboard screen capture) plus a third (capture from an external VGA source via an Epiphan grabber) for a former employer. I had the best bandwidth-to-quality ratio with VNC, but I got higher framerate with VGA capture. In all three cases, I reduced the frames + capture times to PNGs and sequenced them in a QuickTime reference movie. Then I made flattened video (MPEG4 or SWF) of the results. In my case, I then synchronized the screen video with a DV stream.
In the end the technology worked (see a sample of the output) but our business model failed.
From what I know, the older versions of applet had security restrictions that may not allow for screen capture. Instead, a java application may be feasible.
Regarding the build-it-yourself vs the fire-a-coder, it depends on how you value your time compared to what you can find on a freelancer site.
I think you can find someone from India/Romania/Poland/Other countries that can make it for an affordable price
Given your Java knowledge and the difficulty of the task, have you considered taking an alternative approach? For example, how about a native VNC server for the end-user, which is just a small download and then they click "Run." And that native server is programmed to capture the screen and send it straight to your web server, which has a client like vnc2swf or other means of converting the VNC stream to a video or .fbs file? Does all that make sense?
Admittedly, without Java, you have to prepare one executable program per platform you want to support, however, I don't know. That still sounds easier to me. Consider Copilot.com. They are doing VNC but they still use small native apps for each platform.
Sorry but this seems the kind of job that requires a lot of experience. Even if you find code snippets all around the net to fix this and that, the overall result may be way worse than simply hiring an experienced Java programmer.