I have a Flex app (SDK 3.5 - FP10) that does mindmap trees. Every node is a Canvas (I'm using Canvas specific properties so I needed it). It has a shadow effect, background color and some small ui element on it (like icons, texts...). It works perfectly until it goes over ~700 nodes (Canvas). Over that number it shows grey rectangles. If I turn off the DropShadowFilter effect for the Canvas, they are also gone, so I assume it's a DropShadowFilter problem.
The effect is simple:
private static var _nodeDropShadow:DropShadowFilter = new DropShadowFilter(1, 45, 0x888888, 1, 1, 1);
_backgroundComp.filters = _nodeDropShadow;
Is it possible that Flex can't handle that much?
I think you're exactly right, flex can't handle that many drop shadow filters. They're very expensive. However, if you're using the built in skins, they create bitmap versions of the dropshadows that are less processor intensive. You'll want to set the style "dropShadowEnabled" to true to enable this effect. You'll have less control over this type of dropShadow, but you may be able to get it to do what you want.
For more dropshadow styles, read the style list of mx:Canvas here: http://livedocs.adobe.com/flex/3/langref/mx/containers/Canvas.html
Yeah, 700 is a bit much for Flex components. At this level you're going to need to write your own custom components that does the drawing & layout manually. Also I agree with using bitmapCaching to make sure the drop shadow filters aren't being constantly re-rendered.
Related
I am developing an app on iOS using JavaFXPorts. I have a Pane that holds a ListView with countries and their flags. I have noticed that ListView scrolling is laggy when I apply the dropshadow effect on the Pane. As you can see from the videos below, without the effect the scrolling is super smooth, whilst applying the effect through CSS, scrolls starts to get laggy. I would like to keep the shadow effect as it makes app more beautiful. So any suggestion is really appreciated.
CSS Code I am using is:
-fx-effect: dropshadow( three-pass-box, rgba(0,0,0,0.6) , 5, 0.0 , 0 , 1);
Video: Scrolling without shadow effect
Video: Scrolling with shadw effect (Laggy)
Please note that this is on iPhone 6 running. On iPhone 5 results are much worse.
When adding effects, css, transitions, custom controls and other complex stuff that typically works fine on desktop, there could be a big loss in terms of performance when being ported to mobile.
Effects
While effects make nodes or panes look fancy, they have the highest negative impact on performance on mobile.
Try to avoid applying them to nodes that change a lot, like cells on ListView, TableView or ComboBox controls.
Also if you apply them to a parent with the referred children (ListView, ...), the parent (and the effect) will be rendered all the time if the children are invalidated (after scrolling, or similar).
If you really need the effect over this parent, try to split parent and children.
Instead of:
parent (Pane with effect)
|-- ListView
you can do something like:
parent (StackPane without effect)
|-- Pane (with effect)
|-- ListView
Since the pane won't change much, you can use Cache over it. Typically, the cache strategy works by rendering an image of the node (pane with effect), instead of recreating all over again the node and that effect, so it is a quick win:
parent (StackPane without effect)
|-- Pane (with effect) and with Cache
|-- ListView
On the contrary, don't use cache on nodes that change a lot (like the ListView).
CSS
Complex CSS requires long CPU time. Try to simplify it. Even you can remove the whole CSS for a quick test. Then decide what you may or may not use.
Try as well to replace some of the styling by code.
Animations
The same goes for animations: Avoid animations, transitions, if possible.
Number of nodes and custom controls
The higher the number of nodes, the lower the performance, so try to keep it to a minimum (replacing complex content with images, canvas when possible).
Switching scenes
Mobile screens are smaller and it is better having less content on each scene than on desktop. Also it is important avoiding switching stages or scenes. Instead use different nodes and replace them over the same scene.
Gluon Charm uses View nodes, and an easy way to switch between different views: MobileApplication.getInstance().switchView("other view name").
Images
Finally, when using images either downloaded from internet or loaded from a file, cache strategies are a must. Have a look at those provided by Gluon Charm Down.
I'm new to JavaFX, but I'm used to developing/designing applications in WPF for C#, and I want my window to be maximizable due to some hefty controls and lists. Is there an equivalent to WPF's margin in JavaFX so the controls will stay put when the window's size changes?
Thanks in advance!
No, there is no exact equivalent in JavaFX 8 to WPF margin support for all nodes.
A feature request to add node margin support is currently scheduled to be implemented for Java 9.
RT-27785 Add "margin" property to node and make it styleable from CSS
For the use case you detail (having controls stay put when the window's size changes), a couple of potential solutions are:
Use an absolute positioning layout container such as an AnchorPane.
Use a GridPane which has margin support.
Tweak the padding values on your nodes.
Set spacing for hbox/vbox style controls.
Using struts as outlined in James Weaver's (somewhat dated and slightly obsolete) document on JavaFX layout.
I'm developing a application which has a ListView which contains items which needs complex cell layouts. The cells are in variable heights and some of the cells tends to be larger than the view port height.
But when the ListView is filled with items the scroll thumb tends to resize its self while scrolling, which makes it hard to hold onto the thumb while scrolling. This happens mainly when passing through different size of cells.
This is not a problem in Swing if I create a same kind of a cell render to be used with the JList. This problem is there in JavaFX 2 and JavaFX8 both.
When looking at the VirtualFlow which is responsible for layout of the ListView and handle scrolling, it seems that the scrollbar thumb side (lenghtbar) is calculated based on the cell count and the visible cell count, which is actually a problem when it comes to lists which has variable heights of cells.
So is this the future of the scroll bar behavior for Java FX list views? or is there any solution available for this problem? Or should I try to hide the scrollbar and provide a different user interaction to scroll?
This problem is already reported under https://javafx-jira.kenai.com/browse/RT-25059 and fixed in Java8 upto some extend. So if this fix is needed on JavaFx2 we have to backport the changes under commit http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/81cc13fe6f96
To get this changes in JavaFX 2.2 you need to apply the required changes on to FX2.2 VirtualFlow.java class and load those changes before the jfxrt.jar is loaded. Another approach is if you don't like to mess up with the jfxrt classes is to have you own ListView which uses your own Skin and the patched VirtualFlow version may be with a different name. But this might require lot of customization compared to first solution.
More approaches are welcome :).
I want to change the background color of my Vaadin app on the valueChange event of a OptionGroup component.
As there are a fairly big number of layouts on my page, what would be the best is to change every HorizontalLayout and VerticalLayout background-color, but every new component that could be added should have this color too.
How can I achieve that? Thanks.
Two approaches come to mind.
The simplest, conceptually, as well as in terms of implementation, would be to have a single component to serve as the background, and give your HorizontalLayout and VerticalLayout components a transparent background. If you're layout is too complex for this, you can have a number of base 'background' components, again, with your layout components on top being transparent. The idea is to reduce the components whose color you need to change to something manageable.
If that approach doesn't translate to your use case, you can always use JavaScript to select the layout components on the fly and redefine their background. This could be made more manageable by giving all the layout components a common CSS class (eg: 'dynamic-background').
JavaScript.getCurrent().execute("$('.dynamic-background').css('background-color', 'purple')");
Note that this JavaScript depends on JQuery, have a look around for more details on integrating JQuery with Vaadin:
Add javascript/Jquery & client side code in Vaadin 7
Integrating HTML and JavaScript in Vaadin 7
Is it possible to get flex renderer recycling while using browser scrollbars?
I have a flex tree control with custom item renderers for rich editing of a server-side data structure which may have any number of child nodes. If at all possible, I'd like to avoid using a flex scrollbar if the content exceeds the viewable range, instead preferring to scroll with the browser's scrollbar. I could use javascript and ExternalInterface to resize the application when the tree's size changes, but my understanding is that this would cause renderers to be created for every row in the tree, which I would like to avoid for performance reasons.
The Flex Tree component doesn't support something like that out of the box. It will create enough renderers to fill it's entire height, assuming the data provider is that large. Since you want it to be larger than the browser window, it will create more renderers than those bounds.
If you were willing to subclass or patch the existing Tree, you could probably add new properties to override the starting value and the height used for the calculation of the number of renderers needed. I'm not sure how much work this would be, but it could be as simple as overriding a single function where this calculation happens.
Obviously, when the browser scrolls, you'd need to pass new values for the start and end values of what's displayed in your Tree.