shlajin

Members
  • Content Count

    16
  • Joined

  • Last visited

About shlajin

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. shlajin

    pixi.loader: How to clear resources up?

    That's starting to get crazier. I tried to make an illustration of how memory consumption increases, but ended with a demo how it doesn't get consumed at all: Here's the playground: VRAM stays at 12 MB constantly on my machine https://www.pixiplayground.com/#/edit/qT4ZDt3fV02z51_gdHC7X
  2. shlajin

    pixi.loader: How to clear resources up?

    I do believe you though Debugging is easy with some understanding which metrics I should observe... At this point I just don't understand how is it possible: why things loaded via PIXI.loader increase my GPU usage, while creating & using textures via new BaseTexture don't
  3. shlajin

    pixi.loader: How to clear resources up?

    These are interesting points! That's what I do on a daily basis I'm mostly concerned that I'm not cleaning things up from VRAM, since I can't easily analyse it. However, you've mentioned... nothing happens when I hit shift+escape (I assume that it may be because you're on windows and I'm on mac). Are you referring to this http://take.ms/ur0Nn ? The problem with it is that I don't think it lists memory consumption correctly. Or, most likely, I get things wrong... If I create `HTMLImageElement` on my own, load image there, then create `PIXI.BaseTexture` and load texture there via `baseTexture.loadSource(image)`, then my memory usage stays under 15Mbs all the time. Even if I load 1.5K images, it changes just by a couple of MBs... My OS Activity Monitor reports that RAM usage is increasing though. I don't display all images at the same time, rather than playing them one by one (essentially I have 1 sprite and I'm changing `.texture=` property there). If I load things with `PIXI.loader.add`, then Chrome's FPS/GPU memory meter instantly shows memory usage spike. And memory drops to the initial usage again, when I perform my cleanup routine. export const cleanupUsedResources = () => { let descriptor:string | undefined // descriptor is the JSON file with spritesheet info while (descriptor = descriptors.pop()) { const cutTextures = PIXI.loader.resources[descriptor] Object.keys(cutTextures.textures!).forEach(key => { cutTextures.textures![key].destroy(false) }) const baseBigResource = PIXI.loader.resources[descriptor + '_image'] baseBigResource.texture.destroy(true) delete PIXI.loader.resources[descriptor] delete PIXI.loader.resources[descriptor + '_image'] console.log("Resources now", PIXI.loader.resources) // empty! PIXI.utils.TextureCache gets cleaned too, btw } } My best guess is that PIXI is smart enough to unload the "old" texture from the memory and load the new one synchronously, while keeping things in memory when I use internal loader...
  4. Hey there! I have a huge spritesheet which I load with `PIXI.loader.add('descriptor.json')`. It works great, however, I want to release memory after I used it and I can't find the right method for it. I can access it (and it's base texture) via `PIXI.loader.resources` dictionary and run `.destroy(true)` on every texture, and then delete values from the hash. However, I'm not sure that this is intended approach and I have OCD that I'm doing things wrong. So, what's the right way? Any advice would be highly appreciated! PS: If I understand how things work, this spritesheet will be collected automatically by PIXI GC after some time; however, I use PIXI.settings.GC_MODE = PIXI.GC_MODES.MANUAL, so... yeah.
  5. So, save files to .dds in the other friend and pick them via main thread... am I right that I'll still have to load them via `new Image().src="my_file.dds"` or is there any other method for this? Also, would highly appreciate if you could suggest some library to process svg -> dds
  6. > If possible, you can even do this at build time and ship the images in the built format. Unfortunately, it's not possible since I'm going to re-size images a lot (from large ones to small ones) and I need to have them as crispy as I possibly can, so vector -> raster is a way to go. > I would build the images on a separate thread and write them to disk, then the main thread loads them from disk. This sounds like a great idea to me, thanks! But at which point will it gain performance? In which format should I save them – png or there's some more "raw" format I can go with?
  7. So, I played a bit and got to this point (it'll take a bit to load images): https://codepen.io/shlajin-the-encoder/pen/aQBvjo I'm not sure why, but in my chrome browser's `createImageBitmap` behaves way better than inside an electron app – I can tell the difference in browser, but I cannot inside electron. Maybe it's something to do with chromium versions – chrome is 70, while latest electron has somewhat like 68/69 (it's in beta and different pieces give different info...) Nonetheless, even in chrome I still feel a noticeable lag which I'm trying to tackle. Is it any close to the bleeding edge or I can do something else to fix it?
  8. Yeah, I did look at it, but it feels like it may bring just some of the work behind the main thread, hence the original question. Thank you for your help – frankly, at this point I don't have stuff setup yet, so I can't test. My idea was to start the "right way" from the scratch, but apparently there's no single silver bullet here. So, I'll continue with "silly" and straightforward way for now and then try to tune that with `createImageBitmap` and report back with results in case anyone else is wondering or encounter the same issue ... and, well, maybe continue discussion if results would not be as good as I aim them to be. Thanks again!
  9. Resource loading happens asynchronously anyway, and since I have SVG I already use `data:xml/svg ...` as `image.src`, so I don't think I can win anything here... I've read through the SuperAtlas code and frankly, I don't understand how that can help 😕 either I don't get something, or I'm bad at explaining my problem... by any chance, is there any SuperAtlas usage example with regular JPG/PNG? I don't think it matters what type of image format is used, the non-blocking way of preparing images do...
  10. Hey there! I'm developing an electron app, which will load shit tons of SVG files and play them as animations. The process of decoding SVG -> PIXI.Texture is pretty fast, however, with 1000 SVGs it takes some time to process... which makes sense. What I'd like to do is to keep the decoding outside of main thread, so user can interact with the system while images are loaded. Since I'm using electron my first attempt was to spawn/fork a sub process and it failed dramatically, because only JSON-encoded data can be exchanged between them. Bummer. Another option is to use electron's protocol to communicate between browser windows (IPC), which doesn't work too, since for some reason IPC can exchange even binary data, but when it comes to built-in stuff like `new Image` it fails to do so. While, theoretically, I could encode images in something else and transfer them I understand that most likely I'll lose more on added overhead... and well, I'm trying to decode less on main thread, not add something more to do so. By searching through this forum I found few threads which discuss possibility of using service workers and, specifically, `createImageBitmap`. Since I'm using electron I can use both, and, luckily, it even supports SVG decoding! A very nice example: https://svg-zoom-demo.glitch.me/ However... I'm not quite sure what am I doing. In my perfect world, I'd use a "loading stub" as a texture for AnimatedSprite, and then, after my promise resolves, swap textures by simply changing them `animatedSprite.textures = newTextures`. How deep can I go there? Is it possible to prepare Pixi's `Texture` to do that off the main thread? Or if I rasterize SVGs with `createImageBitmap` (and scale it accordingly altogether) I will have a huge boost already? But if I do so, will it result in X2 VRAM usage (rasterized image + a new one created by PIXI)? The latter question may sound silly, but I'm concerned about VRAM since I load a lot of images into VRAM and have no ability to check its usage... Maybe somebody has some thoughts? Help is highly appreciated!
  11. shlajin

    Multiple textures from the same URL

    Got it, thanks for help Great work btw, keep it up!
  12. shlajin

    Multiple textures from the same URL

    BTW, what's your technique to parse SWFs? I have sequences of SVG animations, which take up to 30x more space than SWF animation (and that makes perfect sense) – is there a way to convert SWF file to PIXI.Texture[]? (Sorry if this question is unrelated – I can move it to another thread)
  13. shlajin

    Multiple textures from the same URL

    Oh, I see. Is pixi-v5 anywhere ready to somewhat usable in production? If so, where can I find an example how you do that? Thank you!
  14. shlajin

    Multiple textures from the same URL

    Fiddle: https://jsfiddle.net/shlajin/vym4zpu3/ Explanation: I use 2 same textures with different URLs and try to have no texture scaling + scale the Sprite for the first sprite, and texture scaling + no Sprite scaling for the second Sprite. Second sprite looks way better than the first one! If I try to re-use the URL, pixi cache kicks in which doesn't try to scale / recreate textures anymore and therefore, the final size of a Sprite is the original size of the texture. I'm not sure if I'm going the right way here tbh, so... why / what I'm trying to do: it's an app where user can add characters to the scene and freely transform their size. Characters are ".svg" files, which PIXI rasterize upon loading (it makes sense). I'm trying to make them look better, so I decided to re-render textures every time user changes the character size. The second problem I can think of here is that user may add 2 same characters with different sizes, so I some sort of have to have the same texture rendered in multiple sizes?... I dunno. Maybe you can give me a piece of advice? Highly appreciate it!