These are chat archives for pixijs/pixi.js

10th
Jun 2016
Chad Engler
@englercj
Jun 10 2016 03:12
@Bartzy If anything calling RAF after the tick callbacks would make the browser skip a frame (call it later). But mostly it doesn't matter for the use-case of Ticker
@ivanpopelyshev I do read most things that come through pixi, but your idea of "ready" and mine differ greatly. Be patient, we don't need to put every single feature into the lib at once. The review/test/merge takes time, people, and thoughtfulness; and results in a higher quality library.
@ivanpopelyshev I rarely have a good hour to two to dedicate to running through a proposal, and the implementation, and building test cases, and thinking through the effects on the library, and considering the archetecture of core vs plugin.
Takes time, which I am in short supply of right now.
Dr. Kibitz
@drkibitz
Jun 10 2016 04:56
@Bartzy requesting after like @englercj said may result in the browser skipping calling you back for a single frame. But the reality is that for the ticker, the reason is because execution on the current frame may have resulted in not needing request a new one, so checking afterward is accommodating that fact. If frame execution would cause a frame skip, it would not be more than one frame because if execution would cause skipping more than one frame, then it doesn't matter requesting before or after emitting listeners, it will have still skipped n or n+1 frames depending on timing. The +1 frame at a refresh rate of 60hz
Or 60fps rather ;) it isn't really disernablr
Wow, I can't type, sorry
Dr. Kibitz
@drkibitz
Jun 10 2016 05:01
anyway... If it really is something you are seriously worried about. Then my suggestion would be to add a "tock" to the ticker, and move all your heavy lifting there.
something to note, if you have more than one RAF loop, it really doesn't matter
"tock" being a second event, after the RAF
at that point we're really emulating flash with enter and exit frame
Dr. Kibitz
@drkibitz
Jun 10 2016 05:09
If this is something people are interested in, I guess the current "tick" would be the equivalent of exiting the frame, and
following the raf would be enter? Or vice versa ;)
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 12:21
@englercj manipulation with rendering order appears almost in every game
its not like "every single feature" , that thing is critical, it was requested on forums countless times
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 12:32
and its not first edition, I already refined it and made a better example, which, i think, counts as a test
Ove
@bakken
Jun 10 2016 13:46
Ahoi ahoi, is there way to have a PIXI.Container with transparent background so i can layer two Container on top of each other? Can’t find anything in docs.
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 13:47
stage.addChild(first); stage.addChild(second); second.alpha = 0.5;
if you have background as a child of second, then secondBackground.alpha = 0.5;
In general, your question does not make sence: containers are just groups of elements, they dont have a background on their own
they dont even have their own texture
they're not "windows" or "layers", they are groups
width height and bounds of a container depends on its children
Ove
@bakken
Jun 10 2016 13:55

thanks for the quick reply. still learning pixi. i’ve got on »foreground« Container with PIXI.Sprites added to it and another »background« Container which i plan to use as a composition cache for the foreground.

There’s only ever on sprite animated on the foreground Container, the rest stays static. Does this make sense to you?

Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 13:55
yep
so you can use something like
background.cacheAsBitmap=true;
that also depends on which projects are you doing
will it be in production, or is it a demo?
do you want to use CanvasRenderer if webgl is not available?
if its demo, and webgl only, dont even bother with making static things, PIXI v4 can process 10k sprites at 60FPS just fine
Ove
@bakken
Jun 10 2016 14:00
don’t bother too much about canvas fallback, WebGL only will be fine. I’m trying to build a full screen image slider with transparent .png’s (will be replaced by .jpg’s with alpha mask later on). so i don’t actually need to cache the foreground becuase pixi is fast enough?
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:01
yes.
it depends on:
1) number of sprites 2) number of textures used in them 3) overall drawing area
number of sprites up to 10k is OK
number of textures - better to compile everything into ~8 atlases
Ove
@bakken
Jun 10 2016 14:03
sprites will be between 20–40. drawing area is the whole screen but only one sprite at a time needs to be moved
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:03
drawing area - well, 10 fullscreen images might be a problem.
moving is not important.
do you work with PIXI v4 or v3?
Ove
@bakken
Jun 10 2016 14:04
3 at the moment.
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:04
Ove
@bakken
Jun 10 2016 14:04
can easily go to v4, it’s just a few lines of PIXI code right now
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:05
you will have a problem with arranging children of container in the order you need
just remember that 1-st child is rendered first :)
Ove
@bakken
Jun 10 2016 14:06
sorry, not quite sure what you mean : )
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:07
there's no z-index
children of container are rendered in the order you added them
you can change their order by changing "container.children" array directly
Ove
@bakken
Jun 10 2016 14:11
ahh thanks. the default order is just perfect. it’s actually working quite smooth during the scroll right now (still v3). But when Sprites get into the visible area of the Canvas and Container the animations stutters for a split second. The Sprites not currently visible are set to visible = false. And when moved into the viewable area to visible = true. That’s where i suspect the stuttering happens.
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:11
dont use visible please
use "renderable"
also when something is rendered first time, texture is uploading to GPU
(videomemory)
if your texture is big, well.. its better to preload
renderer.updateTexture(texture.baseTexture);
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:12
for v4 its renderer.textureManager.updateTexture(texture.baseTexture)
update all your basetextures after they are loaded but before game is started
you can add it in "setup"
Ove
@bakken
Jun 10 2016 14:15
is texture.baseTexture a reference to a sprites texture?
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:16
BaseTexture is a wrapped Image or Canvas
Texture is link to BaseTexture+rectangle
you are passing Texture into new Sprite(...)
or new MovieClip(...)
you have to upload base into videomemory first to prevent that stuttering
that happens for really big textures (1024-4096)
Ove
@bakken
Jun 10 2016 14:19
so what i’ll do is loop over all the textures before i create a sprite from them and upload the baseTexture to GPU Memory via renderer.updateTexture(currentTex.baseTexture)
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:19
yes
for v4 its inside "renderer.textureManager"
also if you are using json spritesheets (made by shoebox or texturepacker), all textures created will have the same base, so you have to update it only one time
so you actually uploding entire spritesheets and not just one small region
makes sence?
base is the source. Like, one PNG file.
texture is a rectangle
you have to upload all bases
Ove
@bakken
Jun 10 2016 14:26

not quite sure if i understand the spritesheet solution.
this is what i’ve got for the texture upload:

this.renderer.updateTexture(PIXI.loader.resources[slideUrl].texture.baseTexture);

sprite = new PIXI.Sprite(
PIXI.loader.resources[slideUrl].texture
);

Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:27
yep
you can just iterate over all resources and check if they have texture inside
you can compile the spritesheet using http://renderhjs.net/shoebox/
Ove
@bakken
Jun 10 2016 14:28
wow! thanks so much for all your help. stuttering seems gone now in safari and chrome.
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:28
that will speed things up
you cant use basic pixi optimizations without spritesheets
if there are sprites with the same base texture, they will be batched in 1 drawcall.
Ove
@bakken
Jun 10 2016 14:31
hmm, all my sprites have a unique texture, like in an image gallery. so this might not be of use for this case?
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:35
are they big?
if they are then yep, you dont need a spritesheet
Ove
@bakken
Jun 10 2016 14:40
yes, they are 2144 x 1066 px
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:45
ok, then the loop is the solution
Ove
@bakken
Jun 10 2016 14:48
ok, perfect : ) next up is resizing and retina screens… does pixi automaticly adjust for retina? tried to search for it, but can’t get a clear picture. if you know a good ressource i’m happy to read that
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:49
yes
automagically
look
renderer = new PIXI.WebGLRenderer(width, height, { resolution: window.devicePixelRatio });
either you also pass autoResize: true
either you do renderer.view.style.width = width+'px'; for yourself
that's two things
got it?
1) specify the resolution for renderer
2) either set autoresize either set style for canvas manually
3*) if you have custom textures for @2x, then load them instead ("lalala@2x.png")
4) pledge some money to Mat Groves (https://www.patreon.com/user?u=2384552&ty=h&u=2384552)
Ove
@bakken
Jun 10 2016 14:55
sure will do 4) great tool.
will go with autoresize first and see if it keeps aspect ration. still have code the image resize function
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 14:57
thing is with autoresize: we need style width/height be same as inner width and inner height, right?
but canvas itself must have 2x pixels
so actual renderer.width , renderer.height (view.width, view.height) will be 2x times more than you pass to it
You dont have to change anything in containers and sprites coordinates
just deal with renderer resolution and CSS :)
and assume that actual viewport in pixi isnt (0,0,renderer.width,renderer.height)
but (0,0, renderer.width/renderer.resolution, renderer.height/renderer.resolution)
that will help you if you actually using these variables to estimate if element is visible or not
Ove
@bakken
Jun 10 2016 15:02
ahh thanks
Dr. Kibitz
@drkibitz
Jun 10 2016 16:59
@ivanpopelyshev FYI, your example is unbearably slow on my iPhone 6s
The sorting example
Ivan Popelyshev
@ivanpopelyshev
Jun 10 2016 17:10
because 40 filter blur :)
I really need to fix that