I am using Leap Motion with processing utilising the Leap Motion for Processing library. (Leap Motion for Processing Lib)
I am however struggling to find a way to use scaleFactor as seen in Java Leap Motion documentation. (Java Api Docs)
I want to access this functionality in order to create a zoom function in my application when moving hands away from each other.
Any help would be much appreciated!
I took a quick glance through the processing library that you are using and it didn't look like it exposes the scale factor or other motion attributes from the Leap Motion Frame class (which is where you would get the scale factor for two-handed motion). That's not a library created or maintained by Leap Motion. I suspect your options are to use the Leap Motion Java library directly or to get the feature added to the processing library you are using.
It looks like you would add the feature you are trying to use in LeapMotion.java -- but you should discuss this with the developer who created the library.
I found a solution to this issue in the form of an alternative library. It means I will have to recode the gestures I have already created due to the libraries working differently but I do now have access to the Frame class which I was missing before.
This is the library I am now using... https://github.com/heuermh/leap-motion-processing
Below is a simple snippet of code which shows the scaleFactor working...
import com.leapmotion.leap.Controller;
import com.leapmotion.leap.Frame;
import com.leapmotion.leap.processing.LeapMotion;
LeapMotion leapMotion;
float zoomFactor = 0;
void setup()
{
size(16 * 50, 9 * 50);
background(20);
frameRate(30);
leapMotion = new LeapMotion(this);
}
void draw()
{
fill(20);
rect(0, 0, width, height);
fill(200);
rect(0, 0, (zoomFactor * 100), (zoomFactor * 100));
}
void onFrame(final Controller controller)
{
Frame frame = controller.frame();
Frame sinceFrame = controller.frame(25);
zoomFactor = frame.scaleFactor(sinceFrame);
println(zoomFactor);
}
Related
I was looking for a way to properly choose the monitor I want to fullscreen on based on the position of the window prior to fullscreening.
I looked online for ages but couldn't find anything so I ended up trying a bunch of things until I got something working.
I figured someone eventually will try to look this problem up and I might as well share my solution.
What I ended up doing is get the virtual screen coordinates of the center of the window using LWJGL2's Display class like so:
int x = Display.getX() + Display.getWidth()/2,
y = Display.getY() + Display.getHeight()/2;
I then used AWT to get all available monitors:
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices()
I iterated through them and got their virtual bounds(and applied any DPI scaling they might have):
Rectangle bounds = screenDevice.getDefaultConfiguration().getDefaultTransform().createTransformedShape(screenDevice.getDefaultConfiguration().getBounds()).getBounds();
EDIT: Slightly altered line so it can support Windows' DPI scaling properly.
If the bounds contained the center of the window, it means that most of the window is probably within that monitor:
if(bounds.contains(x,y))
return bounds; //getMonitorFromWindow()
Then to toggle between windowed borderless fullscreen and normal windowed in LibGDX I did the following:
// config is the LwjglApplicationConfiguration of the application
// upon changing using alt+enter
if(fullscreen) {
config.resizable = false;
Gdx.graphics.setUndecorated(true);
Rectangle monitor = getMonitorFromWindow();
// set to full screen in current monitor
Gdx.graphics.setWindowedMode(monitor.width, monitor.height);
Display.setLocation(monitor.x, monitor.y);
} else {
config.resizable = true;
Gdx.graphics.setUndecorated(false);
Rectangle monitor = getMonitorFromWindow();
// set to windowed centered in current monitor
Gdx.graphics.setWindowedMode((int) (monitor.width * 0.8f), (int) (monitor.height * 0.8f));
Display.setLocation(monitor.x + (int) (monitor.width * 0.1f), monitor.y + (int) (monitor.height * 0.1f));
}
I hope someone would find this useful.
The image quality and the framerate I get when using the camera2 API does not match the one I get when I manually record a video using the camera app to a file.
I am trying to do real-time image processing using OpenCV on Android. I have manually recorded a video using the built-in camera application and everything worked perfectly: the image quality was good, the framerate was a stable 30 FPS.
My min SDK version is 22, so I am using the camera2 API's repeating requests. I have set it up, together with an ImageReader and the YUV_420_888 format. I have tried both the PREVIEW and the RECORD capture request templates, tried manually setting 18 capture request parameters in the builder (eg. disabling auto-white-balance, setting the color correction mode to fast), but the FPS was still around 8-9 and the image quality was poor as well. Another phone yielded the same results, despite its max. FPS being 16.67 (instead of 30).
The culprit is not my image processing (which happens in another thread, except for reading the image's buffer): I checked the FPS when I don't do anything with the frame (I didn't even display the image), it was still around 8-9.
You can see the relevant code for that here:
//constructor:
HandlerThread thread = new HandlerThread("MyApp:CameraCallbacks", Process.THREAD_PRIORITY_MORE_FAVORABLE);
thread.start();
captureCallbackHandler = new Handler(thread.getLooper());
//some UI event:
cameraManager.openCamera(cameraId, new CameraStateCallback()), null);
//CameraStateCallback#onOpened:
//size is 1280x720, same as the manually captured video's
imageReader = ImageReader.newInstance(size.getWidth(), size.getHeight(), ImageFormat.YUV_420_888, 1);
imageReader.setOnImageAvailableListener(new ImageAvailableListener(), captureCallbackHandler);
camera.createCaptureSession(Collections.singletonList(imageReader.getSurface()), new CaptureStateCallback(), captureCallbackHandler);
//CaptureStateCallback#onConfigured:
CaptureRequest.Builder builder = activeCamera.createCaptureRequest(CameraDevice.TEMPLATE_RECORD);
builder.addTarget(imageReader.getSurface());
//setting the FPS range has no effect: this phone only has one option
session.setRepeatingRequest(builder.build(), null, captureCallbackHandler);
//ImageAvailableListener#onImageAvailable:
long current = System.nanoTime();
deltaTime += (current - last - deltaTime) * 0.1;
Log.d("MyApp", "onImageAvailable FPS: " + (1000000000 / deltaTime));
//prints around 8.7
last = current;
try (Image image = reader.acquireLatestImage()) { }
On Samsung Galaxy J3 (2016), doing Camera.Parameters#setRecordingHint(true) (while using the deprecated camera API) achieves exactly what I wanted: the video quality and the framerate becomes the same as the built-in video recorder's. Unfortunately, it also means that I was unable to modify the resolution, and setting that hint did not achieve this same effect on a Doogee X5 MAX.
Is it possible to create a photosphere in JavaFX that is similar to photoshpere in Google map? If yes, how?
The answer is yes, you can create a photosphere in JavaFX.
As for the how, there's an easy solution based on a sphere from the 3D API, but we can implement an improved solution, with a custom mesh.
Let's start by using a regular sphere. We just need a 360º image, like this one.
As we want to see from the inside of the sphere, we have to flip the image horizontally, and add it to the sphere material's diffusion map.
Then we just need to set up a camera in the very center of the sphere, add some lights and start spinning.
#Override
public void start(Stage primaryStage) {
PerspectiveCamera camera = new PerspectiveCamera(true);
camera.setNearClip(0.1);
camera.setFarClip(10000.0);
camera.setFieldOfView(90);
Sphere sphere = new Sphere(1000);
sphere.setCullFace(CullFace.NONE);
PhongMaterial material = new PhongMaterial();
/*
"SonyCenter 360panorama" by François Reincke - Own work. Made using autostitch (www.autostitch.net)..
Licensed under CC BY-SA 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:SonyCenter_360panorama.jpg#mediaviewer/File:SonyCenter_360panorama.jpg
*/
material.setDiffuseMap(new Image(getClass().getResource("SonyCenter_360panorama_reversed.jpg").toExternalForm()));
sphere.setMaterial(material);
Group root3D = new Group(camera,sphere,new AmbientLight(Color.WHITE));
Scene scene = new Scene(root3D, 800, 600, true, SceneAntialiasing.BALANCED);
scene.setCamera(camera);
primaryStage.setTitle("PhotoSphere in JavaFX3D");
primaryStage.setScene(scene);
primaryStage.show();
final Timeline rotateTimeline = new Timeline();
rotateTimeline.setCycleCount(Timeline.INDEFINITE);
camera.setRotationAxis(Rotate.Y_AXIS);
final KeyValue kv1 = new KeyValue(camera.rotateProperty(), 360);
final KeyFrame kf1 = new KeyFrame(Duration.millis(30000), kv1);
rotateTimeline.getKeyFrames().addAll(kf1);
rotateTimeline.play();
}
Now you will want to add some controls to the camera (so you can navigate). You will discover that this solution has a weak spot at the top and bottom of the sphere, due to the fact that all the top or bottom side of the image is located in one point:
You can find a solution to this problem at the F(X)yz library here. A custom mesh called SegmentedSphereMesh allows you to crop the extremes of the sphere, so the image can keep its aspect ratio without being stretched.
If you clone and build the repo, add FXyz.jar to your project, and just replace Sphere in the previous snippet with this:
SegmentedSphereMesh sphere = new SegmentedSphereMesh(100,0,26,1000);
sphere.setCullFace(CullFace.NONE);
sphere.setTextureModeImage(getClass().getResource("SonyCenter_360panorama_reversed.jpg").toExternalForm());
In the same library you can find SkyBox, based on a cube and one square image on each of its faces. Also check the advanced camera options.
Finally, note that this and more 3D advanced shapes are now demonstrated in the F(X)yz-Sampler application.
Okay, I understand your need for an SSCCE, so I created (my first) one.
I managed to replicate the problem with under 200 lines of code. On my system this demo compiled and ran perfectly (only the flickering was still there of course).
I stripped everything that had nothing to do with it. So basically we have two source files now: the screen manager and the game manager.
The screen manager:
http://pastebin.com/WeKpxEXW
The game manager:
http://pastebin.com/p3C5m8UN
You can compile this code with this make file (I use a ported version of Linux' make for Windows):
CC = javac
BASE = nl/jorikoolstra/jLevel
CLASS_FILES = classes/$(BASE)/Game/GameMain.class classes/$(BASE)/Graphics/ScreenManager.class
jLevel: $(CLASS_FILES)
#echo Done.
classes/%.class : src/%.java
#echo Compiling src/$*.java to $# [command: $(CC) src/$*.java ] ...
#$(CC) -Xlint:unchecked -d classes -classpath src src/$*.java
Where the source files are placed in the /src directory and the classes in the /classes directory.
After compilation to byte-code the game can be started using the following .bat file:
#set STARUP_CLASS=nl.jorikoolstra.jLevel.Game.GameMain
#set ARGUMENTS=1280 1024 32
#java -cp classes;resources %STARUP_CLASS% %ARGUMENTS%
Note that the ARGUMENT variable depends on your own screen settings and that you have to change it so that the game is displayed in the right resolution for your screen.
I see why it is flickering ----
BufferStrategy is doing a separate painting job from the Component's paint() method and they seem to use different Graphics objects and they are refreshing at a different rate --
when paint() is invoked before show(), it's fine. But
when paint() is invoked after show(), it will repaint the component to its initial blank look -- so flashing happens.
It's very easy to eliminate the flickering: override paint() method of your JFrame (GameMain) as you don't need it to do anything (BufferStrategy can give you more precise control on painting stuffs):
#Override
public void paint (Graphics g) {}
That's all. (I have tested it and it works fine, hope this may help :))
===== Update =====
Instead of overriding paint() method, a better way is to call setIgnoreRepaint(true) for your JFrame (GameMain) -- this method is just designed for such purposes! USE IT!
private GameMain(String ... args)
{
setIgnoreRepaint(true);
.....
}
This is how i implement double buffering, might help you get the concept.
Note it's implemented in a JPanel, but i think it can be implemented in other containers:
TheJApplet.java:
import java.awt.*;
import javax.swing.*;
public class TheJApplet extends JApplet
{
private Image myImage;
java.net.URL GameURL = CheckerGameJApplet.class.getResource("GameIMG");
String GamePath = GameURL.getPath();
#Override
public void init()
{
String GraphPath = GamePath+"/";
File myImage_File = new File(GraphPath+"myImage.jpg");
try
{
myImage = ImageIO.read(myImage_File);
}
catch (IOException ex)
{
// Add how you like to catch the IOExeption
}
final TheJPanel myJPanel = new TheJPanel(myImage);
add(myJPanel);
}
}
TheJPanel.java:
import java.awt.*;
import javax.swing.*;
public class TheJPanel extends JPanel
{
private int screenWidth = 500;
private int screenHeight = 500;
private BufferedImage BuffImg = new BufferedImage
(screenWidth,
screenHeight,
BufferedImage.TYPE_INT_RGB);
private Graphics2D Graph = BuffImg.createGraphics();
private Image myImage;
public TheJPanel(Image myImage)
{
this.myImage = myImage;
repaint();
}
#Override
public void paintComponent(Graphics G)
{
Graphics2D Graph2D = (Graphics2D)G;
super.paintComponent(Graph2D);
if(BuffImg == null)
{
System.err.println("BuffImg is null");
}
Graph.drawImage(myImage, 0, 0, this);
Graph2D.drawImage(BuffImg, 0, 0, this);
}
}
Hope this helps, good luck.
I have a cross-platform Java AWT-based program with animation. It had flashing problems until I strictly followed the example code at in the Java BufferStrategy documentation. However I'm using an AWT Canvas embedded in a Swing hierarchy, not full screen as you. You can see the code here if interested.
Another thing to note is that the AWT pipeline uses OpenGL primitives for good performance, and OpenGL support is buggy in many video drivers. Try installing latest versions of drivers for your platform.
It may work for you, when you set your hwnd.createBufferStrategy(2) in its own method.
There was a problem with Java rendering transparent background GIF images. That could be the problem.
I find it rather difficult to answer your question without an SCCSE. I also wonder what the RepaintManagerResetter does.
You might want to set your background color to some fancy colors like 0xFF00FF to find out if someone "clears" the background before the drawing happens. If the flicker image is purple, it's that - if it contains garbage or old images, it's probably the double-buffering.
In any case I would try to ensure that noone draws expect yourself. First, try to prevent native Windows code from drawing the window background. Set this once:
/*
* Set a Windows specific AWT property that prevents heavyweight components
* from erasing their background.
*/
System.setProperty("sun.awt.noerasebackground", "true");
Also, make sure that you override this in your JFrame(if you are using Swing components)
#Override
public void paintComponent(Graphics G)
{
// do not call super.pC() here
...
}
If that doesn't help, please provide a working example of your code, so people can reproduce the problem.
When I run my swing GUI applications under Java 6, they automatically use my configured sub-pixel anti-alias settings for all fonts. The result is much improved over standard AA options.
But when I paint to an image I can find no way to initialize the graphics context to use the system's AA configuration. Trying to play around with Java's different AA hints is a lost cause because no sub-pixel method will work for all users.
Is there any way to inherit system AA settings for a given graphics context instead of having to pick one and explicitly set the hint? At the moment I have to use GASP AA to avoid the horrible results that standard AA gives with small fonts. I have tried not setting anything for text AA, and not setting any AA hints at all.
Update 2010-01-05
I think I have pinned this down; the subpixel AA hints appear to only be respected when painting directly to the AWT graphics context; when I paint to a double-buffer image it just does standard AA; but when I bypass the double-buffer image the subpixel AA is done.
Otherwise The_Fire's answer would work in JVMs which have Swing available (but not J2ME JVMs); Note that The_Fire's answer does not work using an AWT component (using new Label() instead of new JLabel() fails), presumably because the FontRenderContext cannot be extracted until the component is realized to the display.
My current code to get the graphics context for my target image currently looks like this:
try {
if((dbImage=dctRoot.createImage(wid,hgt,1))!=null) { // if createImage returns null or throws an exception the component is not yet displayable
dbGraphics=(Graphics2D)dbImage.getGraphics();
if(dctRoot.properties.getBoolean("Antialias",true)) {
try {
// set AA on overall
dbGraphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING ,RenderingHints.VALUE_ANTIALIAS_ON);
// set text AA to platform/impl default
dbGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,RenderingHints.VALUE_TEXT_ANTIALIAS_DEFAULT);
// try to override platform/impl AA with font-specified AA (Java 6+)
try { dbGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,RenderingHints.class.getField("VALUE_TEXT_ANTIALIAS_GASP").get(null)); } catch(Throwable thr) {;} // yes, ignore exception
}
catch(Throwable thr) {
dctRoot.log.println("Antialiasing not supported on this JVM ("+thr+").");
dctRoot.setProperty("Antialias","False"); // turn off AA for subsequent painting
}
}
}
}
catch(Throwable thr) {
dbImage=null;
dbGraphics=null;
}
The code to create the image uses an underlying AWT component, which forms the backdrop on which I do all my painting - the component is a Panel, because I need to be able to do a setFocusCycleRoot so it plays well with other AWT components. The create image code follows:
public DctImage createImage(int wid, int hgt, float accpty) {
GraphicsConfiguration cfg=awtComponent.getGraphicsConfiguration();
Image img=null;
if(transparentImages) {
//y { img=new BufferedImage(wid,hgt,BufferedImage.TYPE_INT_ARGB); } // NB: J2ME CDC/PP 1.1 does not have the BufferedImage constructors (one day I may discover a way to create a BufferedImage via another API!!)
try { img=cfg.createCompatibleImage(wid,hgt,Transparency.TRANSLUCENT); }// NB: J2ME CDC/PP 1.1 does not have this API, but prefer to use GraphicsConfiguration over new BufferImage(...)
catch(NoClassDefFoundError thr) { transparentImages=false; createImage(wid,hgt,accpty); } // try again with transparency disabled
catch(NoSuchMethodError thr) { transparentImages=false; createImage(wid,hgt,accpty); } // try again with transparency disabled
catch(NoSuchFieldError thr) { transparentImages=false; createImage(wid,hgt,accpty); } // try again with transparency disabled
}
else {
img=cfg.createCompatibleImage(wid,hgt);
}
if(accpty>0 && SET_ACCELERATION_PRIORITY!=null) {
try { SET_ACCELERATION_PRIORITY.invoke(img,new Object[]{new Float(accpty)}); } catch(Throwable thr) {;}
}
return (img==null ? null : new DctImage(img));
}
I found there were a few factors going on here.
First, the image needs to be created from the underlying AWT component, and it must be created without transparency:
cfg.createCompatibleImage(wid,hgt);
instead of
cfg.createCompatibleImage(wid,hgt,Transparency.TRANSLUCENT);
Second, for some inexplicable reason, the primary AA setting, KEY_ANTIALIASING, must be off to use LCD subpixel AA.
Lastly, and most importantly, the desktop font rendering hints are easily retrieved using:
java.awt.Toolkit.getDesktopProperty("awt.font.desktophints")
Update 2010-01-05
Retesting in Java 6.26, it seems like the problem with needing to set general AA off to render text AA has finally been resolved (way to go Oracle... after Sun was just a few years decade too late).
Using Swing, I'm able to get the right text anti-aliasing hint like this:
JLabel label = new JLabel();
FontMetrics fm = label.getFontMetrics( label.getFont() );
Object aaHintValue = fm.getFontRenderContext().getAntiAliasingHint();
On my system this returns RenderingHits.VALUE_TEXT_ANTIALIAS_LCD_HRGB.
java.awt.Toolkit.getDesktopProperty("awt.font.desktophints") appears to be null on linux, at least without any special vm command line options, presumably because it's unable to figure out what the platform defaults are.. adding e.g "-Dawt.useSystemAAFontSettings=lcd" seems to cure it and enables subpixel rendering if you set the hints on your Graphics2D instance.
Wait, are you running this code on a Windows JVM? I thought ClearType was a Microsoft technology that Swing inherits through some native code (ie, not available on Linux or other non Microsoft platforms).
I once wrote a servlet that generated JPGs with anti aliased fonts that ran on Debian, and this was the code I used
Font font = new Font("Komix", Font.PLAIN, 8);
Graphics2D g2;
g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
FontRenderContext frc = g2.getFontRenderContext();
g2.setFont(font);
g2.setPaint(Color.black);
g2.drawString(sMessage, xOffset, yOffset);
Offhand I can't recall if any of this code relies on Swing (I imported javax.swing and the servlet is about 300 lines long, so I may have thought I needed it for something else), a quick check on Google looks like this is squarely in the AWT space. Hope that helps.