Let's say I'm creating a jar file and have an icon in an asset folder to be included in the jar.
So before using, stage.getIcons().add(icon); in my code is there any particular advantage or disadvantage to having the icon as
Image icon = new Image("Assets/Icon.png");
Vs.
Image icon = new Image(getClass().getResourceAsStream("Assets/Icon.png"));
Both seem to work fine, so I'm looking to pinpoint which I should generally gravitate towards and why.
There's a related topic here but it compares loading styles mostly with web applications.
javafx.scene.Image(String) calls validateUrl, which does additional processing of the String value, including checking the current Threads contextClassLoader for the resource.
The advantage of using something like Class#getResourceAsString is you've already made the decisions for the class, which would be (slightly) faster, but also less ambiguous and would probably be easier to diagnose should you have issues (as you control the source mechanism for the image itself) and aren't leaving the decision making up to code that you don't immediately control (and since validateUrl is private static, can't change)
Related
Often when I'm coding in javafx, and using different graphical user interfaces and panes, I come across the word pref, as a prefix to method names, sometimes in contrast to a max/min prefix for the same method name. Sometimes pref behaves weirdly. This may be because I'm not using the pane correctly, or because I'm misinterpreting what the "pref" methods do. Can someone explain what is meant by pref, and what it does in terms of code. I'm just started learning coding, so please break it down in the simplest way possible.
This is because an UI system generally let applications request for a size that may not be possible to obtain. Just think of an application requesting for a window of size 10000x10000 but the host UI system can manage such (because the screen size is 400x400 for example), then you will be served for only 400x400.
A good UI application must not enforce sizes or anything like that, but request for sizes and then behave according to what the host gave in return.
For our SWT-based application we are getting relatively often the SWT error "no more handles". To detect whether the problem is in our code, how to detect - using code in our application - how much handles our application actually is using?
If I understand you correctly, you are probably getting the following exception:
org.eclipse.swt.SWTError: No more handles
You may be creating resources (such as Font, Image or GC objects) that you aren't correctly disposing.You might want to take a moment to read through SWT guide on Managing Operating System Resources.
To determine if this is indeed the case, I can recommend this useful article: Diagnosing Handle Leaks in SWT/RCP Windows Applications.
Use Sleak, it is also a way to monitor your resources.
In the "Processes" tab of the Windows Task Manager you can add the "Handles" column, showing the handles all your process use in real time.
Baz' tip for Sleak gave me the idea:
final DeviceData data = new DeviceData();
data.tracking = true;
display = new Display(data);
and then in regular intervals I log the number from
final int handleCount = display.getDeviceData().objects.length
Unfortunately, detecting the number of widgets (I guess, they are using handles, too) is not possible so easily.
I recently read this article on ClientBundle and under the Levers and knobs section, see these two entries:
ClientBundle.enableInlining is a deferred-binding property that can be used to disable the use of data: URLs in browsers that would otherwise support inlining resource data into the compiled JS.
ClientBundle.enableRenaming is a configuration property that will disable the use of strongly-named cache files.
I'm having a tough time visualizing these in action and understanding what they do. Where do you set these properties? Why would you set them (i.e., when would I want to "disable the use of data", or "disable the use of strongly-named cache files")? Can someone provide a real-world use case and perhaps some code snippets for me? Thanks in advance!
Where do you set these properties?
Deferred-binding properties are set in your gwt.xml with <set-property>.
See https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsDeferred
Why would you set them (i.e., when would I want to "disable the use of data", or "disable the use of strongly-named cache files")?
For debugging, or if the performance boost they're supposed to bring to your app actually does more harm than good (enableInlining'), or if you need/want to share the resources with other scripts/apps (enableRenaming`).
Can someone provide a real-world use case and perhaps some code snippets for me?
You'll know it when you need them. Until then, ignore them.
In case this is still useful, I have a real-world example of needing to disable inlineing.
But first, just to clarify the code needed its simply;
<set-property name="ClientBundle.enableInlining" value="false" />
In your XML to disable the use of DataURLs and use image strips instead
I had to do this in my code, because my project requires animated images. Even a basic sprite with just a few frames has very bad performance when using DataURLs. The browsers just struggle to update and display the images at anywhere near a reasonable framerate.
By comparison, the use of image strips, vastly speeds up performance. The browser merely has to change the cropping.
In fact, given the lack-luster browser support for animated PNG's, if you need animated images, this is probably the current best way to do it.
I am trying to use the AssetManager class in LibGDX and I understand how it works but I am trying to implement a loading screen. I have followed the AssetManagerTest.java file here,
but I am having a hard time trying to figure out how to get it to work correctly. Can someone point me in the right direction? My goal is to load the assets (textures, sounds, fonts, ... etc) and update a bar with the percentage complete on the screen. I don't understand the ResolutionFileResolver and the Resolution[] in the link I provided. What are they for? My goal is to support a static class that can give me access to all of the assets I need in my game from any screen. Is there a preferred method to do this? Thanks.
After looking at the source for ResolutionFileResolver as well as the other 'resolvers', I think it's just a way of loading textures that best match the screen resolution, but the match is just based on filename patterns.
So in AssetManagerTest, he's got textures for screen sizes 320x480, 480x800, and 480x854. It looks like each group of textures should be in a directory called ".320480" or ".480800" or ".480854" (although the name can be anything you want, like "low", "high", and "wide" if those are your directories), and he specifies all this info when creating the array of resolvers on line 56 of the test.
The advantage of doing all this stuff is that when he calls manager.load(), he just picks out a filename like "data/animation.png". Then the resolver finds the pack of textures that most closely matches the current screen resolution, and loads that one.
I think the rest of the example should be pretty clear, at least for the basics of AssetManager. Create a manager, set the loader, call load(), call get() to use it, and then call unload() when done.
For updating a progress bar, you'll just need to do that manually after each call to load.
And using a static class for asset management is certainly one possibility. Another similar option is to just use a singleton. It has its haters, but I think in a simple project in a garbage collected environment it should be ok, although it's about the same as a public static.
Another option--maybe the best?--is to use a base class that has a static copy of your game globals, and then all other game classes inherit from it. This is the approach used in Replica Island. See the base class and the object registry. Replica Island is well commented and worth checking out for Android & Java games.
I'm developing a swing based application where I'm using many FileDialogs? So I say why not to make just one FileDialog object instead all of these instances and use it in the whole project? Is this a good assumption? does this have any performance improvement?
Thanks
This is a great example of a use case where application performance doesn't really matter and the question actually falls into the premature optimization class of problem solving. Why? Using FileDialog means that you are interacting with the user who, even if skilled beyond skilled with shortcut key Kung Fu, will be many orders of magnitude slower than the application. How many FileDialogs could a speedy user open, use and close in one minute? Say a dozen. You should not need to care about a dozen objects coming and going in one minute. Shouldn't even appear on your radar. Use your energies elsewhere. In fact, you should create a new object every time and avoid any caching headaches.
I would make a static FileDialog class that generates a new instance of the FileDialog each time a new one needs open rather than sharing a Singleton instance across the application.
That'll save you the headache of trying to figure out if you're reading the correct path from the dialog box or if somebody has opened the dialog and picked a new path and now you're referencing that new path rather than the originally selected path, etc...
Why implement is as a Singleton? Can you actually verify that displaying two file dialogs will never occur?
Better to have it as a regular class; you don't want to build in limitations which could become pain points later.
It isn't like your application is going to be critically overloaded by millions of calls to the file dialog, and who knows, perhaps someday it will be the right solution to have two file dialogs. Even if you don't display them both at the same time, perhaps holding the history in a "source" dialog and having a separate history in the "destination" dialog would be a blessing in a file transfer program.
Forget performance/speedyness. It doesn't matter here. Semantics matter. Reusing the same file dialog may give you things for free. Will the dialog start in the same directory every time? It will if it is the same instance. If you are creating new dialogs you will have to set startup dir your self.
Also why make it impossible to create more than one instance? Just make an instance member in your frame and be done with it.