shlajin

Members
  • Content Count

    20
  • 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. Very nice, thank you for the great job! I use 4.7, so this library works great as a starting point for me. Thank you for CLI tools also, really helpful
  2. I found a demo of MSDF and the animation looks amazingly smooth! That's what I needed, thank you so much for the keyword to google For any others wondering, this what I found https://github.com/soimy/pixi-msdf-text
  3. Thank you for your response. SDF Text doesn't seem to fit my goals, unfortunately. I made a quick video where I animate the text using this package and, as you see, on smaller font sizes it has some extra-sharpness artifacts. Same as if I go with big fontSize and just scale it down via `scale.x / scale.y`. Tried with antialias on and off, no real difference That's what I did for now – I took the middle between the largest and the smallest sizes, so if text animates from 80 to 160, I use fontSize of 120. This ensures that the text doesn't look too bad when it's big and when it's small... However, I really want to try to make it look better than that. I tried with no effect – AFAIK Pixi always forces mipmaps whenever possible. I'm starting to think of reinventing the wheel and switch textFont size only on certain values and use scale.x/scale.y in between...
  4. Hey there! I'm trying to scale text during animation (namely – during camera zooming) while keeping it smooth & sharp. Scaling with `.scale` doesn't work well for this case – text gets pixelated, so I went with redrawing the text by changing the text style `fontSize` property. This is slow, but this isn't shown to the user in real-time, so I don't care about FPS during that. The problem with this approach is that text shakes/shivers during the animation. This doesn't happen when I animate `.scale` property and I want to avoid that. So I tried different approach: I created text at maximum fontSize and then shrank it down via scale and animated scale. Shivering almost gone, but some nasty artifacts such as over-sharpness appear when scale is low... so I thought – maybe mipmaps can help me there? I hacked pixi and tried to do this inside Text#updateText: const width1 = Math.ceil((Math.max(1, width) + style.padding * 2) * this.resolution) this.canvas.width = Math.pow(2, Math.round(Math.log(aSize) / Math.log(2))) width1; const height1 = Math.ceil((Math.max(1, height) + style.padding * 2) * this.resolution) this.canvas.height = height1; this impacted text metrics a lot, mangling text positions but I didn't notice any positive change on the text quality. So, maybe I'm doing something completely wrong. What's the correct way of doing this? Thank you in advance!
  5. 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
  6. 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
  7. 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...
  8. 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.
  9. 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
  10. > 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?
  11. 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?
  12. 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!
  13. 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...
  14. 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!