• Content Count

  • Joined

  • Last visited

About shlajin

  • Rank

Recent Profile Visitors

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

  1. That's amazing news. Looking forward to try it out!
  2. Just wanted to say that your work is very much appreciated! Do you have a rough idea when it's going to happen? I'm on a waitlist for it since the initial release of v5 😁
  3. 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
  4. 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
  5. 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...
  6. 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!
  7. 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
  8. 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
  9. 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 ? 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...
  10. 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.
  11. 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=""` or is there any other method for this? Also, would highly appreciate if you could suggest some library to process svg -> dds
  12. > 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?
  13. So, I played a bit and got to this point (it'll take a bit to load images): 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?
  14. 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!