Exca

Create canvas with full resolution. Change the renderer resolution and canvas width/height with css. So for example something like this: Canvas width & height values always at 3840 x 2160. 3840 x 2160 => CSS width & height as 3840 x 2160, resolution 1 1920 x 1080 => CSS width & height as 1920 x 1080, resolution 0.5 1280 x 720 => CSS width & height as 1280 x 720, resolution 0.33 and so on.

Sorry, cannot currently take freelance work.

Webgl context loss happens when os tells the browser that I need some resources, please free them immediately. Or it might happen also if for some reason the context is taking too much resources. You could check how heavy your app is to render with tool like spectorJS. In theory it's possible to handle context loss so that it resumes when context is ok once again. For more info see https://www.khronos.org/webgl/wiki/HandlingContextLost

You need to remove the object from stage to make it disappear. Also delete only removes the reference, you might also want to call the destroy function of the sprite (maybe even destroy the texture if it's no longer needed).

Use extrude (TexturePacker has this at least) to fill in extra amount of "correct" color to outside of the actual pixel area of the image. That way AA wont mess up by blending nearby empty area into end result.

Use a boolean value to indicate when mouse is on & check in render. Or add the render listener when pointerover happens & remove it with pointerout. Or if you dont prefer events you can do a hittest and see if current pointer position overlaps with your object. For example let isOn = false; sprite.addEventListener("pointerover", ()=>isOn=true); sprite.addEventListener("pointerout", ()=>isOn=false); const onRender = ()=>{ if(isOn){ // do something. } }

In line 56 you are flipping the y-coordinate which causes the texture to read from negative y-value and I'd assume your basetexture has wrapMode set to clamp so it reads the pixels from the edge. Remove the - sign from that line and it should work.

In the thumbnail movement you should calculate the effect of frame delta time. So t_.x += config.thumbnail.speed * delta.

You could extends the pixi loader with custom solution or maybe there's some middleware way to add headers, though couldnt find one with quick glance of loader implementation.

You can render your container into a renderTexture. https://pixijs.download/dev/docs/PIXI.RenderTexture.html

Use compressed textures & spritesheets would be the solution. If you have for example 400 1024x1024 32 bit png images then uncompressed that would require 13.4 gigabits of video memory assuming my calculations were right (might not be, but large amount of memory anyways). Also 400 is such a high number that no gpu currently can hold that many texture slots so batching is not possible -> no benefit in using particle-container, it might even be decremental to performance as it's intended for cases where a single texture is used for lots of sprites. For some reason I couldnt see the example running so dont know what the resolutions were. But if they are small enough you can get it working with just spritesheets. If it's still sluggish then try compressed textures. If it's still slow then things get much harder and I know of no simple solutions.

Texturepacker has a split sheet tool that can at least extrat fixed width sprites. Dont know if it supports plist type.

You have to either stop the event from propagating to the parent in sprites drag start to block it's dragstart from starting or keep the sprite and rectangle separate.

You are also creating a new offscreen canvas on each event. That will consume lots of memory fast. Can you reuse a single canvas?

How large canvas did you have? If it goes over your gpus texture size limit then at least that could happen. You can check https://webglreport.com/ to see max sizes.

Then for timing logic I would keep a track of lifetime for each object (either ms or frames) and add tickers delta (or deltams) from that time in the loop that handles movement. Then calculate the current phase of the particle by simple currentTime/targetTime. If phase is over 1 then the animation is complete and particle can be removed. Otherwise calculate the position/alpha based on that phase value. For the movement question. Every displayobject (be it sprite, text or container) in pixi has a position value and they indicate the position in relation to parent. So if you have a container in position 100,100 and under that you have your particles in positions 10,5 ; 11,-9 ; -5,5 then they would show on screen in positions 110,115 ; 111,101 and 95,105 assuming your container is a parent of stage container (or stage itself) and it has not been scaled/rotated. And for the coordinate axis to be on the center you can just move your main container (or this might require additional, I cant remember if root containers position affects) to center of screen: container.x = app.renderer.screen.width/2.

Are you using some particle engine or using sprites inside a container with selfmade movement/spawning logic?

Try using "rightdown", "rightup", "rightclick" and see if those work. Or use a separate contextMenu listener on canvas and call preventDefault on that.

Yeah, you can create a base texture with canvas and then render a sprite that has that as a texture. const canvas = document.getElementById('my-canvas'); const canvasBaseTexture = new PIXI.BaseTexture(canvas); ccnst canvasTexture = new PIXI.Texture(canvasBaseTexture); const sprite = new PIXI.Sprite(canvasTexture); stage.addChild(sprite);

Yep, that looks correct. Though I'd suggest testing first if it works by using smaller region from current textures (for example use 4x4 area and 2,2 offset of texture instead of current 8x8 and confirm that it fixes the issue). With automatic spritesheet tools (like texturepacker) you can create that extra data automatically with extrude -setting.

Ah, didnt mean rendering 2 sprites per tile. But rather have the basetexture be 2px larger than the actual texture in each direction. So if you have a 8x8 basetexture then make it 12x12 and create the texture with 8x8 starting from 2,2. This way when subpixels on the edge of texture are rendered they will be interpolated between same color as what the edge is, instead of interpolating with whatever is near to that texture.

Might be due to AA -issues when rendering hits subpixels. Are you using texturepacker or similar tool for spritesheets? You could try using extrude of 2 pixels, might help. Or do the extrusion manually by creating the textures with 2px padding (new Rectangle(2,2,8,8) and have original image 4 px larger.

With filters you will force yourself off from batching. In that sense they are a problem when you get batching to work for spines.

Checked the data now. Getting batching to work would help a lot. Having 1k+ drawcalls is a lot and as a consequence having many drawcalls means a lot of commands (11k+), these would drop also with batching.

I'll check the data later today. About batching I'm not very familiar with it's internal workings and batching. Hopefully someone else has more info about that.