I am trying to draw some bar graphs with a data set that contains overlapping priorities.
E.g. three bars of different colors may be drawn at one point, but the one with the highest priority will be shown. This works most of the time, but I am getting some artifacts on my plot as some of the colors from lower priorities leak through occasionally. Any ideas of where I can look to fix this problem?
I thought it may have been an anti-aliasing issue, but turning it on or disabling it has no effect on the artifacts.
When I've seen things like this before it was because I was graphing multiple data series, and for the most part there was a huge overlap in the datasets and only the last dataset rendered (top one) was visible most of the time. I suspect that whatever you are doing in your hide code might not be working as well as you think and the 'bleeding' of the other colours is the datasets where the overlap is less significant. Try an experiment and change the order in which your datasets are rendered - I'll bet that you see suddently that the predominant colours of your bars change.
I'm not quite sure what you mean, but you probably should remove the priorities you don't want to see from the data model altogether, then they won't be painted at all.
Related
I have javafx pane containing about 50000 of shapes. When I cache pane with CacheHint.Speed it is fine for Zooming and Panning. But it is so blurry when zoom. If set to CacheHint.Quality it becomes so sluggish.
I am trying the solution of playing with CacheHint but unable to catch OnScrollFinished event on desktop. Clipping the pane doesn't help.
I am thinking of selecting viewed shapes to render instead of rendering all shapes but what is the efficient way for checking about 50000 shapes?
Could some please help me with some options.
Thank you
The first thing I would do is to analyze which of your primitive types has the major effect on performance and then start optimizing that.
Paths are notoriously slow in JavaFX (compared to Lines and Rectangles for example).
Replace SVGPaths which just represent simple Lines and Rectangles by
the JavaFX counter parts if you can.
Simplify the paths if you can.
Remove all geometries from the scene graph which are currently not visible.
Use a triangle mesh to display your geometries. If done right this gives you a real performance boost but it is a lot of work (I've done it :-)
Using lots of tiny images may also be very slow. If that is the bottleneck it might help to create a texture atlas from your images and use a triangle mesh to display them.
In LibGDX, I am currently trying to achieve the effect of a pixellated GUI, meaning the buttons are pixellated, like an 8-bit theme.
When I make my GUI elements, such as a TextButton, I am using images that are small, say 34x16 pixels, but I am rendering them on a large resolution like 1920x1080. What is the best way to render such a small image at a high resolution?
My thoughts were to use stage.setViewport(WIDTH,HEIGHT), and set the width and height to a scaled down resolution, so the gui elements wouldn't be so big. This works, however when adding elements things go wrong.
This my stage/table currently, using a scaled down resolution. I am adding widgets using to the table like this:
table.add(playButton);
table.row();
table.add(title);
but as you can see, the table.row() makes a row that is much too large, perhaps a row fit for a larger resolution. Is there any way to change the gap that is made by the row? I would have thought that the gap would be zero, and by using table.add().pad() you could change the gap, but I am not doing any of that.
Any help would be greatly appreciated.
Ninepatch
This is a common issue in all apps. To overcome this, images which can be safely resized in parts are used. they are called ninepatches.
Here is a nice Tutorial about using them in libgdx.
Distance Field Fonts
Although you haven't mentioned it here, you'd also find font sizing (pixellated fonts) as an issue. For that Distance Field Fonts are used.
Hope this helps.
I would say don't worry about scaling them up and making the virtual resolution bigger. If you want to see picture still pixelated when you scale it use Texture filter. For your case you want to use Nearest filter. use it like this:
yourTexture.setFilter(TextureFilter.Nearest, TextureFilter.Nearest);
where yourTexture is the texture that you have all your bitmaps and skin elements on. If you are using texturePacker than you can specify the filter before packing too. Or just open the .pack file and on the top you will see filtering options, and edit those to Nearest.
Is it possible to change the edge shape in JUNG? For example, I would like to have the edge change it's color gradually in a way similar to a progress bar. What about the edge label font size?
Thanks.
Yes, sort of... Also - I'm not sure which version of JUNG you're using, but this works in the latest JUNG 2 release (I realize JUNG 3 might be under development currently, but last time I checked, it wasn't stable enough to be used for production-level code).
1. Labelling: First, you need to implement the Transformer<EdgeType,Font> interface that converts your edge instances into Font instances. Then call [VisualizationViewer instance].getRenderContext().setEdgeFontTransformer([Transformer<EdgeType,Font> instance]).
2. Color/Stroke Customization: This is a little trickier, because the only way you can have this change color gradually (that I am aware of) is by creating a Transformer<EdgeType,Paint> that returns different paints for edge type instances over time. There are several transformers used for edges - these control the draw, the fill, and the Stroke, and have similar method names like the one mentioned for the labeller in step 1. You will either need to control when the graph panel repaints manually or ensure that JUNG's animation renderer is turned on so that repaints happen continuously.
I'm currently trying to improve the performances of a map rendering library. In the case of punctual symbols, the library is really often jsut drawing the same image again and again on each location. the drawing process may be really complex, though, because the parametrization of the symbol is really very rich. For each point, I have a tree structure that computes the image about to be drawn. When parameters are not dependant on the data I'm processing, as I said earlier, I just draw a complex symbol several times.
I've tried to implement a caching mechanism. I store the images that have already be drawn, and if I encounter a configuration that has already been met, I get the image and draw it again. The first test I've made is for a very simple symbol. It's a circle whose both shape and interior are filled.
As I know the symbol will be constant in all locations, I cache it and draw it again from the cached image then. That works... but I face two important problems :
The quality of the drawn symbols is hardly damaged.
More problematic : the time needed to render the map is reaally higher with caching than without caching. That's pretty disappointing for a cache ^_^
The core code when the caching mechanism is on is the following :
if(pc.isCached(map)){
BufferedImage bi = pc.getCachedValue(map);
drawCachedImageOnGeometry(g2, sds, fid, selected, mt, the_geom, bi);
} else {
BufferedImage bi = g2.getDeviceConfiguration().createCompatibleImage(200, 200);
Graphics2D tg2 = bi.createGraphics();
graphic.draw(tg2, map, selected, mt, AffineTransform.getTranslateInstance(100, 100));
drawCachedImageOnGeometry(g2, sds, fid, selected, mt, the_geom, bi);
pc.cacheSymbol(map, bi);
}
The only interesting call made in drawCachedImageOnGeometry is
g2.drawRenderedImage(bi, AffineTransform.getTranslateInstance(x-100,y-100));
I've made some attempts to use VolatileImage instances rather than BufferedImage... but that causes deeper problems (I've not been able to be sure that the image will be correctly rendered each time it is needed).
I've made some profiling too and it appears that when using my cache, the operations that take the longest time are the rendering operations made in awt.
That said, I guess my strategy is wrong... Consequently, my questions are :
Are there any efficient way to achieve the goal I've explained ?
More accurately, would it be faster to store the AWT instructions used to draw my symbols and to translate them as needed ? I make the assumption that it may be possible to retrieve the "commands" used to build the symbol... I didn't find many informations about that on the world wide web, though... If it is possible, that would save me both the computation time of the symbol (that can be really complex, as said earlier) and the quality of my symbols.
Thanks in advance for all the informations and resources you'll give me :-)
Agemen.
EDIT : Here are some details about the graphics that can be rendered. According to the symbology model I'm implementing, graphics can be really simple (ie a filled square with its shape) as well as really complex (A Label whose both shape and fill are drawn with hatches, for instance, and even if a halo around it if I want). I want to use a cache because I'm sure that in most configurations I'll be able to :
differenciate the parameters that have been used to draw two different symbols of the same source that are styled with the same style.
be sure that two sources with the same parameters (location excepted) will produce the same symbol for the same style, but at two different locations (only a translation will be needed).
Because of these two points, caching seems to be a good strategy. Moreover, there may be thousands of duplcated symbols to be drawn in the same image.
You are awefully vague about what kind of operations your drawing really entails, so all I can give you are some very general pointers.
1.) Drawing a pre-rendered Image is not necessarily faster than drawing the same Image using Graphics2D operations. It depends a lot on the complexity required to draw the image. As an extreme case consider fillRect() vs. a drawImage() of an Image containing the pre-rendered rectangle (fillRect just writes the destination pixels, where drawImage also needs to copy from a source).
2.) In most cases you never want to mess with VolatileImage directly. BufferedImage takes advantage of VolatileImage automatically unless you mess with the Image DataBuffer. If you have many pre-rendered images you may also run out of accelerated video memory and that degrades image drawing performance.
3.) On-the-fly scaling/rotating etc. of a pre-rendered image can be pretty costly (depending on the platform and current graphics transformations).
4.) The 'compatible Image' you create may not really be compatible with the drawing target. You obtain an image compatible with the default screen device, which may not be compatible with the actual target in a multi monitor setup. You may get better results using the actual target components createImage().
EDIT:
5.) Translating the coordinates of a rendering operation may alter the destination pixels produced. An obvious case is when the coordinates are non-integers (either in the coordinates themselves or indirectly through the AffineTransform set on the graphics). Also, antialiasing of text and possibly other primitives may be influenced slightly by coordinates (subpixel rendering comes to mind).
You could attempt an approach that differentiates on if a symbol is presumably fast or slow to render. The fast ones being rendered directly, while the slow ones are cached. The main problem here is in deciding which ones are fast/slow, I expect this to be non-trivial to decide.
Also, I wonder when you say there are thousands of symbols to be rendered, as I imagine most of them should be clipped away since only a small portion of the graph fits into a Window/Frame? If thats the case, don't bother much with caching. Drawing operations that are completely outside the current clip bounds will be relatively cheap - all the graphics target really does for them is detection if they are completely invisible and when they are just do nothing. If the goal is the produce an image to be saved to disk/printed (whatever) I wouldn't bother much with speeding up the rendering, since this is a relatively rare operation and the actual printing may by far exceed the time needed for rendering the graph anyway.
If none of the above applies to your case, be somewhat careful that your cache does not use more time/memory to decide if a cached version exists than it really saves in rendering time. You also need to take into accound that building a cached image instead of rendering to the target directly does cost you some time if that image is never reused. Caching can only gain you some speed if the image is reused at least once, preferably many more times.
If you build your symbols from primive operations by combining primitve rendering operation objects (like there is a Rectangle, Halo and Text rendering object subclass), you may want to assign each of them a cost indicator and only cache those symbols that exceed some (to be determined) cost threshhold. Also it may be a good idea to implement a hashCode() for each primitive operation and the symbol itself for fast(er) equals detection.
I'm writing some Java OpenGL code (though the principles are the same in C++ openGL). I have a situation where I want to render certain items on top of others. I can do that by disable the depth test or by setting it to GL_ALWAYS) for those items and that works well. The issue is that colors of those items on top seem to be darkened by the items underneath it. I'm not sure if it's a lighting issue or if it's some blending issue but I'm trying to show the item's color without being affected by the colors around it, regardless of this item's z-position (since depth testing is set to ALWAYS). Is there a lighting setting or blending setting I should be using for this?
thanks,
Jeff
I think in this situation, I'd leave the depth settings alone, but adjust the Z value of the objects based on the drawing order (for those items you want drawn based on order instead of normal depth).
glBegin(GL_WHATEVER);
for (int i=0; i<num_objects; i++)
glVertex(object[i].x, object[i].y, i/-100.0f);
glEnd(GL_WHATEVER);