0

I'm trying to make a Famo.us game where I have a background Image ( an ImageSurface ) and then I put a bunch of other ImageSurfaces over the top and animate them. However the background surface doesn't stay in the background, for starters new ImageSurfaces are drawn underneath, then weirdly they start getting drawn on top. Exact same code generating the surfaces.

the background image has a Transform.behind applied to it.

The image below kind of shows the problem, some of the small squares are behind, and some are on top.

If it makes any difference, the surfaces are all in a HeaderFooterLayout

Any ideas whats going wrong? or how I could debug this?

enter image description here

Keith Nicholas
  • 43,549
  • 15
  • 93
  • 156

1 Answers1

1

check the zIndex value of the surfaces isn't the same as the zIndex of the white surface you're attempting to hide them behind. If they are the same (or unspecified) the browser hazards a guess, and you end up with z-fighting where the GPU can't actually decide what to render (the white surface or the tabs?) You could have your tabs resting on one zIndex value, and the white surface on the other.

(The following is written by Keith) For anyone else, what I did was add the following to the ImageSurface

 properties: {              
    zIndex: -1000000
 }    

Oddly I tried with a zIndex of -10 etc, which didn't work, only once I made that zIndex huge did it seem to fall behind everything else.

Keith Nicholas
  • 43,549
  • 15
  • 93
  • 156
Kraig Walker
  • 812
  • 13
  • 25
  • isn't that what the Transoform behind is supposed to take care of? In the picture, the white is supposed to be in background, the little squares are supposed to be on top of the white one, I just moved the white image to the side so you can see whats happening – Keith Nicholas Jul 23 '14 at 21:50
  • I'm afraid I don't see any Transform.behind method in the Famo.us docs. This may have been a custom variable in an example you saw or something. Anyways. Surfaces are still just DOM elements. CSS styling rules still apply. It'd be difficult to have a "behind" method/attribute because the question would be "behind what??" There would need to be a comparison of other objects/surfaces which may/may not exist. Otherwise, you'd have to make a crazy assumption the next DOM element you find can have it's z-index compared. – Kraig Walker Jul 24 '14 at 22:44
  • it was in the docs, looks like maybe they took it out, in my starterkit docs I still have it on the "Transform" page...METHOD inFront (Property) Array defining a translation forward in z by 1 METHOD behind (Property) Array defining a translation backwards in z by 1 – Keith Nicholas Jul 24 '14 at 23:09
  • Ahh I see where you're coming from. The Z Axis in space and the Z index in layout are two different things. Technically you can have something in front of another by translating it along z, but z index tells the gpu what to draw first and will override it. So if the zIndex is up in the air, even though they're translated in z, the GPU is still making things up as it goes along when objects intersect. – Kraig Walker Jul 25 '14 at 08:46
  • yeah, thats how I thought you were supposed to do it, I saw somewhere change the zindex doesn't work properly on firefox. But I haven't tried it for my situation – Keith Nicholas Jul 25 '14 at 09:26