Avoid drawing of hidden components (FLEX) - performance

We have big components to draw. Now we have performance problems. We are using visible and includeinlayout properties to hide some components, but they are still rendered by flex.
Is there a possibility to avoid that?!
Is it only possible if we delete the component from the displaylist or can we somehow override the draw method of the component and check if it is hidden or not and depending on that it will be drawn or not.??

Whatever components you don't want drawn yet, put in any SkinnableContainer based container with creationPolicy="none" (don't create my children for me automatically). Then later on ... if and when you want flex to create those components, you can do this:
// here frame is my container with creationPolicy="none" set on it
public function update():void{
if(frame && !frame.deferredContentCreated){
frame.createDeferredContent();
}
}

Related

Edit Worldspace UI layer?

I need to have my worldspace UI render over my ceiling layer; however, there's no way to edit the render layer for the object. How can I fix this?
I believe you are looking for the Sorting Layer option in the Canvas component:
You can create a custom layer which renders on top of everything else like so:

Qt Quick: Can I use the layout components for item layout, without the overhead of rendering the items to the window?

I want to render a QML subtree manually to a Canvas3D by having all the subtree's items' be-texture-source flag (layer.enabled) enabled, and taking the geometry (x, y, width, height) of each item from the corresponding QML properties of each item (calculated by layouts, anchors, etc), so I know how to position and size each item with OpenGL calls.
I have no problems with implementing this, except for a performance issue: since I'm drawing the items in OpenGL, I don't want Qt to also draw them to the window (this would be doing the same work twice). I could achieve that easily by setting opacity: 0 on the items, but that would probably only fix the visual problem, it wouldn't save performance. I could also set visible: false but then I think the layout components wouldn't be able to do their job correctly.
The reasons I want to implement the described architecture are:
I want to implement custom rendering for some of the items in the subtree, but still use their positions and sizes (calculated by the layout for me) for the custom rendering. This custom rendering is complex enough that it can't be done with QML features alone, and I don't want to use Qt3D.
I could use use another approach: use a separate Canvas3D for every item that I want to render customly. And let Qt Quick render the rest of the items for me normally. That's what I've been doing until now. The problem, however, is that:
The different Canvas3Ds can't share GL resources, so I need to initialize and keep copies of the GL resources in each Canvas3D. This increases load time and memory usage.
The creation time of each Canvas3D (even without my GL init code) is significant, I think
So instead I want to use a single, big Canvas3D.

Custom Draw in NSView without erasing the previous background

I am trying to plot few points dynamically on my Custom View using Quartz functions so that i get a complete graph. I handle drawing of lines inside the drawRect method of Custom View where I get the current context and draw the lines. But, they get erased when i try to draw a new line. I want to have those lines also visible along with the new ones drawn. Please let me know how to do this. I can't store all the points together and draw at the end. I want to continously update my view. Thanks in advance.
Add a method to your custom view:
- (BOOL) isOpaque { return YES; }
That will prevent the drawing of any views behind yours including the background.
Note, however, that on resize you'll need to redraw everything either way. A more proper solution would be to use off-screen image to draw into instead.
You could use CALayers: add a new child layer to the root each time you have new data, and draw to that layer. Your drawing code can remain the same: you just need to put in the code for creating and using layers, which is actually pretty easy.
See: http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreAnimation_guide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40004514

change image on hover using gwt and ui-binder

i am using the declarative/ui-binder method of adding images to a page. this is in combination with using the ImageBundle functions that GWT provides.
what i would like to do is change the image out when i hover over the image. my questions are: what are the best way to do this, and is my current method the best method in the first place?
my code looks something similar to:
<ui:with field='res' type='path.to.my.app.AppResources' />
...
<g:HorizontalPanel ui:field='horizPanel' >
<g:Image ui:field='image1' resource='{res.image1}'/>
</g:HorizontalPanel>
that is then tied into an ImageBundle class via the AbstractImagePrototype.
then, in my main handler, i have something like:
#UiHandler("image1")
public void onMouseOver(MouseOverEvent event)
{
/* What do I do here? */
}
say i want to replace image1 with image2 when the user hovers over image1 (and put image1 back when the pointer leaves the image). do i replace the image1 object? do i use the setUrl function for that image? do i create a whole new image, and use the add/remove functions for the horizontal panel to add it on? that seems awfully inefficient. do i not even need an ImageBundle; can i add images via something like <g:Image .... url='path/to/image1.png' /> and then use CSS and the hover attribute to swap out the image?
some guidance would be great. the GWT documentation is seriously lacking in this area. thanks.
PushButton is good for this kind of behavior. You can go father than :hover - you can specify arbitrary html and widgets for different faces of the buttons.
See gwt pushButton in UiBinder for an example in uibinder.
There will be more overhead in this approach, since it does register mouse handlers and set up a whole widget - if you really only need the rollover image and not any other event handling, a :hover css selector (maybe with a #sprite?) is probably best.
Using mouse handlers here seems a little overhead. I would use css and the hover selector
.foo {
background: url('path/to/image1.png');
/* height, width, etc. */
}
.foo:hover {
background: url('path/to/image2.png');
/* ... */
}
then use a widget that renders a div element (e.g. SimplePanel) instead of an image and set the style foo as stylePrimaryName
<g:HorizontalPanel ui:field='horizPanel' >
<g:SimplePanel ui:field='image1' stylePrimaryName='foo'/>
</g:HorizontalPanel>

"CoreAnimation: surface is too large"

I'm creating a custom (layer-hosting) document view, which is contained within a scroll view. The root layer has two sub layers of the same size--one for the view's content, and one for anything that needs to hover over the main content. I set the frame to 2500x2500 and added a number of cells to the content layer, which was fine. On adding a translucent clone of one of the cell's layers to the overlay layer, the whole view clears briefly, and I get a log message 'core animation: surface 2502x2502 is too large'. This happens between adding the new layer and the next cycle of the event loop, so I guess when core animation renders the new layer.
I knew that a layer's content size is related to opengl texture size, but didn't think its frame mattered. I'm not drawing anything to these layers, not setting any style properties, and remove offscreen sub layers. All I'm really using them for is to handle the geometry of the document view. Is this an appropriate use of CA layers? If not, are there better ways of handling a large core animation-based document view?
Edit:
I've had this problem again, caused by an implicit animation on adding sublayers to the large parent. So in addition to what is suggested below, that's one to check if you run into this.
I would check to make sure that you're not setting any properties on your 2500x2500 layers which could require offscreen rendering. (This causes the layer to try and create a full-size buffer off-screen and render its contents into that buffer, rather than just rendering the contents to the screen directly.)
For example, setting an opacity, masksToBounds, mask, shouldRasterize, etc, could cause offscreen-rendering. You can see if offscreen-rendering is happening with the Core Animation instrument. (There's a checkbox to highlight offscreen-rendered areas.)

Resources