This question is very open and probably, the answer to this question will depend on the system, but say in average which is the best way to show a large matrix (say 128 elements) of different states?
Create one control for each cell and let GUI library deal with all events and stuff (In Windows 128 HWND:s)
Draw the entire matrix by using lower-level graphics primitives
Is there a difference in memory/CPU performance depending on choice? The number of states in my application is 4 for each cell so they need 2 bits each to represent their state. Each cell will be represented by an image related to the state.
Sure there is a difference. I will try to illustrate this and also the assumptions this is based on.
Cost of a control = memory for control + event handlers for control + references to control + one extra control in event pipeline
Benefit of "tight" control per cell mapping. Conceptually clean, simple code, easiest to think about.
Cost of tight mapping : multiply the cost per control by the number of cells.
The alternative I'm about to suggest assumes that the cost delta between tight mapping and a loose "one ring" mapping is important.
alternative : just add one control that is registered for events only within the bounds of the whole matrix view you present, has a piece of code to determine the pointer position and what cell that corresponds to, and then updates only that cell depending on the user interaction there.
The advantages of this are you get the marginal cost of only one extra control but the benefit of handling interactions for the entire matrix. The marginal benefit or this control is much higher than for a single tight control. Aldo, the implementation cost is small as it is a common pattern and not too difficult.
Good luck!
Related
I'm working on a form that shows many our company's products in a FlowLayout, but on some categories that hold many products, performance in scrolling is noticeably affected. I switched to a List so I could leverage the performance benefits of using a renderer, but now I'm not happy with the layout since there's a lot of wasted space, especially if the device is in landscape mode.
My next thought was to use a Table, which I believe also uses renderers to optimize the display of its data; but to mimic a FlowLayout, I'd need to get the preferred width of some placeholder component, then divide the container's width by that to get the number of columns, and then fill the model with that number of columns in mind. I'd also need to change all that if the device changes orientation.
Before I go down that rabbit hole, I'm wondering if I'm making things unnecessarily complicated for myself and if there's already something that I can use to achieve that goal. So to summarize, what would be the most efficient way to display data (that would be shown as buttons) sequentially from left to right, and top to bottom?
I wouldn't use FlowLayout for anything serious although I doubt its the reason for your performance issues, those probably relate to something else. There is a performance how do I video which is a bit old but mostly still relevant: http://www.codenameone.com/how-do-i---improve-application-performance-or-track-down-performance-issues.html
In design terms flow layout is hugely problematic since the elements are not aligned properly thus producing a UI that doesn't look good when spanning multiple rows. I suggest using a grid layout which has a mode called auto fit. By using setAutoFit(true) on a grid of even 1x1 all the elements will take up all available space uniformly based on screen size and adapt with orientation changes.
I'm looking at some new options for displaying a percentage value as a fill in a custom shape. Consider the effect to be similar to a "progress thermometer" in a traditional dashboard UI sense.
Considerations
Goal - a graphic element showing a percentage value for a custom report.
Format - Either a full graphic (or infographic) itself, or part of a PDF via Photoshop/InDesign or even iBooks (as an excuse to use it).
Usage - I'd like the process to be programmatic, for re-use. It needs to be accurate, and I'd like the solution to be somewhat object oriented to apply to other datasets and graphical containers. This rules out hand-drawn charting.
Source data - currently a pivot table in Excel, but I can work with any other host as required.
Shape - is a custom vector shape that will originate from Illustrator/Inkscape. final format as best fits resolution and rendering of the report. I would also be interested in any other generative shape ideas (such as java/javascript).
Fill - I'd like to be able to represent the fill as both an actual percentage of total area (true up), and as a percentage of the vertical scale. I'd imagine this flexibility would also help reuse of the method as a fill value against selected object variables (height, area, whatever).
I know I'm being slightly vague in the programming languages or hosts side of things, but this gives me an opportunity to break out of the usual analytic toolchain and scope out some innovative or new solutions. I'm specifically interested in open source solutions, but I'm very keen to review other current methods you might suggest.
This might be a little open ended for you, but d3.js is very powerful. There might be some useful templates on the site, or you can build your own from the library.
If you limit yourself to shapes where the percentage can be easily converted into a new shape by varying one of the dimensions, then the display part can be covered by creating a second shape based on the first one, and filling in 100% of the second shape.
This obviously works best with simple shapes like squares, rectangles, circles, etc, where it is simple to convert "50% of the area" or "75% of the height" into manipulation of vector nodes.
However, things gets significantly more difficult if you want to support genuinely arbitrary custom shapes. One way to handle that would be to break up a complex "progress bar" into "progress pieces" (e.g. a thermometer bulb that represents 10% of total progress, then a simple bar for the remaining 90%).
As has been mentioned, D3 seems like it would meet your needs - here are some simple examples of what I think you are asking:
Changing the fill color of a distinct shape: http://jsfiddle.net/jsl6906/YCMb8/
Changing the 'fill amount' of a simple shape: http://jsfiddle.net/jsl6906/YCMb8/1/
I am looking to style my application with some graphic elements. Icons and other thinks.
Is it better from performance and best practise point of view to use vektor graphics (XAML) or turn my graphic to a PNG?
And Why?
I am aware of the fact that vector graphics are scaleable... this is just a performance questions on large xaml based apps.
You have to weigh your own needs. If it's solely performance, then I'd say that depends on the number of images. If they're a large number then XAML would indeed be more performant, otherwise it would be negligible.
But I have to say for sheer maintainability, especially since you're talking about icons and such, you're far better off with bitmaps and I'll tell you why. Anyone and their brother can edit an icon. You can't say the same with vector graphics. If you want to replace your icons at some point, you simply replace the image. You don't have to go through the hassle of either creating and/or finding vector images and then (most likely) having to convert them to XAML through an export filter. Additionally, there are literally millions of CC licensed icons in bitmap form that you could use for nothing more than attribution.
Yes, there are some hassles with bitmaps (such as some quirks dealing with the ActualWidth/ActualHeight) from time-to-time, but those are minor, in my opinion.
ADDED: Yi-Lun Luo from Microsoft stated vectors are faster back in 2008. With the release of version 3 in 2009, Silverlight has taken advantage of the GPU which makes vectors even faster, if you enable it as well as if you also use BitmapCache. So on from a purely performance standpoint, vectors would be faster, theoretically.
Advantages of XAML over PNG:
Scaling - XAML drawings are made of vectors so are able to scale. Scaling beyond a factor 2 can cause issues (rounding off errors when scaling down and too little detail when scaling up).
Dynamic coloring/animations - You can easily manipulate the colors and points or even curves in the drawing using animations.
Advantages of PNG over XAML:
Speed in loading/caching - PNG can be cached on the GPU. Never more bytes on disk than 4 bits per pixel (+ some overhead)
Pixel perfect - what the designer draws is shown in the app. This is a lot harder when using vectors.
You pick depending on your needs and measurements of performance, load and files sizes.
I'm writing a silverlight app which does some real-time charting. Basically, I just have some polylines overlaid on a canvas. The user can record data for arbitrary amounts of time, and so the width of the canvas is increasing as necessary. Since the canvas is wrapped inside a scrollviewer, it can get quite large. Haven't seen any problems so far, but I haven't implemented the more computationally cumbersome pieces yet, so I'm trying to assess whether this approach is going to cause problems eventually.
Can anyone comment on the efficiency of this approach?
What are some tools/methods that I can use to assess efficiency?
Any other relevant information (I'm not an SL guru)?
Thanks
The canvas is just a coordinate-space for the elements that it contains -- there's no underlying bitmap, so increasing its size has no effect on performance or memory consumption.
You need only be concerned with the number of elements in the canvas, and in particular the number (and complexity) of elements in the visible area.
I have an app that creates a variable number of ScatterviewItems based on which tagged object is placed on the surface table.
The ScatterViewItems are added programatically to the ScatterView based on info looked up in a DB
The Scatterview does a good job of displaying this info
However, I would like them to be
evenly distributed across the table and
not have any items overlapping
Any ideas how to do that?
Sounds like you need collision detection.
There's two parts to this problem: detection and resolution. Detection is seeing if any item's bounding intersects with any other item's bounding. If the items are retangular or circular this is pretty straightforeward. It can get complex if you're dealing with other geometries.
Resoltion is what to do once you've detected a collision. Google will help you find the myriad algorithms for this. Here's a couple links to stackoverflow discussions: WPF: Collision Detection with Rotated Squares, Applying Coefficient of Restitution in a collision resolution method, Best way to detect collision between sprites?.
You can implement collision to work so that items bound off of each other as they scatter. Depending on the number of items, this might cause so much collision that the items don't scatter well. If this happens, just run the collision detection one items have stopped moving.
UniformGrid ?
You can also create your own panel by iheriting from Panel.
You will find some uber-valuable info in the Dr. WPF ItemsControl How-To series : http://drwpf.com/blog/itemscontrol-a-to-z/
That's a must-read, period.
ScatterViewItem has properties Center and Orientation which you can use to programmatically position items. If you know the size of each item you should be able to use these properties to position them in whichever way is ideal for your situation. By hooking into the Loaded event of each and checking ActualWidth/ActualHeight, you can get the dimensions. If you can use a fixed initial size for all of your SVIs, that's even easier.
You could lay them out by calculating a simple grid (plus some randomness to make it look more natural), or you may be looking for what's called a "force directed layout", which gives each object a repellent force relative to its size. After a while the elements will naturally be evenly spaced from one another, though they may still overlap if they run out of room. I haven't seen a WPF example of this, but see flare.prefused.org/demo (layout > force) for what I mean in Flash.