Migrating from v7 to v8

[jakerdy]

Hi!

I am happy to see that Pixi keeps evolving. I realy liked new way of creating object in unified way, especially Text.

I've been trying to port my app to v8. And now I have some difficulties with this process. I want to highlight this so that you could address it in future releases. Also if I mistakenly understand something, hope you will direct me.

All of this related to latest beta (8.0.0-beta6)

[jakerdy]

Text

I have couple questions regarding new Text implementation:

1. How should I load fonts?
   Before it was enough to reference font by name, and some how magically, if font was loaded on page, it also rendered in pixi application. Is it still a case, or I should load it somehow specifically?

2. MSDF. Is it also could be generated dynamically?
   In v7 there was couple of problems with MSDF font layouts becase it ignored baseline metrics, usability was limited, and switching was painfull. MSDF is pretty important if you want to render lots of labels, and have possibility to zoom in. What is current state of it's implementation? How could I help to improve it?

3. Font fallbacks.
   If font doesn't contain some required glyphs, what would happend? Is it possible to specify fallback font chain?

4. How to limit max width for multiline text. And update it after text creation?
   In v7 there was maxWidth property on text node, but now, there is no. In text style you could specify wordWrapWidth. But how could you modify it in runtime? If text block changes it's width via user input.

[GoodBoyDigital]

Ok, so MSDF was a red herring - turns out my test environment was setting all textures to be 'nearest' mapping, so looked all blocky.
The style update issue is fixed here: https://github.com/pixijs/pixijs/pull/

thanks again for such detailed and helpful feedback!

[jakerdy]

About MSDF. There is a project troika-three-text.
It has some nice properties like:

• On the fly glyph generation
• Bidi Support
• Joined Script Support
• Auto font resolving
• etc.

It doesn't support MSDF only SDF. But I did some research earlier this year, and found this: msdfgen-wasm. Which makes it totally possible to render MSDF glyphs in "pure" js, at least in all modern browsers it will work. It could be used as SDF/MSDF/Grayscale(?) glyph generator and metadata source.

Text rendering with unicode support is pretty hard, especially when you should do text shaping your self. If I going to work on MSDF text rendering for Pixi, I would take these libraries as a foundation, cut off unnecessary parts that wouldn't be used, and write some PIXI-related mechanisms/adapters.

Maybe this is not the best way of doing it. Obvious disadvantages: more dependencies that takes precious kb's; code that generates text layout wouldn't match to overall projects codestyle. But on the other hand, it could be done in a reasonable timeframe, because all heavylifting already done by other peoles, and algorithms was already tested within other library. The only thing left is make some adapter / refactor existing api to fit PIXI data structures.

If you are ok with including some 3rd party deps (via embedding), and attributing copyright, it is probably the fastest way of implementing this. If not, it could be packed into separate utility package, and used on it's own. But, integration with existing unified Text system would be nice, but I don't know if it's possible to connect some custom text rendering backends in current implementation.

Anyway, I will work on it at some future, because I need fast and robust text rendering (hundreds of labels with scaling up and down) for my project, and I wouldn't mind implementing this in a generic way that could be useful to someone else. Just tell me which form suits you best, I'll adjust.

[GoodBoyDigital]

this sounds cool, what would be awesome is to add a plugin to AssetPack that transforms fonts to MSDF as a transform process. That way it gets built at compile time!

you could add a font to assets and detect tags:

myFont{msdf}.ttf

transforms to

myFontMSDFTexture.png
myFont.fnt

Using https://github.com/fredli74/Typr.ts this should be super easy!

i think also getting it working at runtime would be rad also. Agree that there is no point reinventing the wheel! A little adaptor over an established tool is definitely the way to go!

[iAmAir]

I have a ported MTSDF/MSDF/SDF/PSDF text generator. It works using WebWorkers over glyphs. How can I embed it?

[jakerdy]

@iAmAir Could you please post a link to repo with code?

[jakerdy]

Pixi Playground

I think I encountered few bugs in v8, but Pixi Playground seems broken for 8.0.0, so that I couldn't make reproducible example to report these bugs.

By default it opens example for 5.3.0, but if you switch to 8.0.0, it couldn't fetch types, and source of default example doesn't fit new async init procedure.

Ok, maybe, if I write some async code by my self it would work, but it's unclear how I should access pixi apis. Is there still PIXI god object, or I should import it. I dont know. For now it's just hard to provide examples of broken behaviour, because playground little bit outdated for now.

[jakerdy]

New Graphics - fillAndStroke

It would be great if you add method like fillAndStroke to new graphics api, in order to elliminate code like this:

const fill: FillStyle = { ... }:
const strk: StrokeStyle = { ... };

// Instead of this:
const gr1 = new Graphics().
    rect(0, 0, 100, 100).
    fill(fill).
    rect(0, 0, 100, 100).
    stroke(strk);

// It would be nice to have this:
const gr2 = new Graphics().
    rect(0, 0, 100, 100).
    fillAndStroke(fill, strk);
    
// I've tried this, but this wasn't worked
const gr3 = new Graphics().
    rect(0, 0, 100, 100).
    fill(fill).
    stroke(strk);

I not sure if 3'rd should work but it still nicer than redundant first.
In v7, you've just set fill and stroke before hand, and draw your figures once.

[GoodBoyDigital]

this should work:

const gr3 = new Graphics().
    rect(0, 0, 100, 100).
    fill(fill).
    stroke(strk);

Just tested and got a stroked / filled rect.
if you can get me a bit more details on the context in which you are using it, i can investigate further! Cheers!

[jakerdy]

Well looks like it somehow related to next one, and other trouble with Graphics that I catch.

[jakerdy]

New Graphics - out of memory

For some obscure reason, I got oom. My app has background grid, which is drawn by graphics using 1px lines. And every next frame take exponentially (or even greedier) more memory. So that in 15 rendered frames, tab just hangs and failed with OOM.

I don't even know how to debug it, in profiler there just more and more time spent evry next frame, and in task manager memory graph grows rapidly fast.
But in my code i just clear graphics every frame, and draw into it couple hundred 1px lines.

I don't know what exactly happens inside there, but it pretty easy to hit this problem. (When palyground will be usable I will provide some working example)
As potential solution, I see providing some hard limit that user could set in order to catch/debug such problems. And when you hit this limit, pixi prints in console something like: "hey, there is 100mb buffer for your Graphics object, it doesn't seems valid".

[jakerdy]

Yep, when I switch back to WebGL it doesn't eats that much memory, no missing strokes and fills, but still littlebit broken, because of missing transforms on some objects. Scene node transforms has correct values, but they drawn at (0,0), like only identity matrix used instead of object matrix.

I decided to refactor my code a littlebit so that it fits v8 niceley, to exclude any mooving parts on my side, and made migration less buggy in the future. First try was some kind'a hacky. For now, I want to change structure of some scene nodes, and viewport handling, make sure that they are works perfectly on v7. After that I'll try move to v8 again. And if something breaks again, I will try to reproduce it in isolated sandbox, and report it as an Issue, so that you have the code to look into.

[GoodBoyDigital]

thanks for sharing - i just put up a PR for the WebGPU issue. #9815
will look into the transform issue now too.

Again, thank you so much for feedback!! v8 already much better thanks to these discussions 👍

[GoodBoyDigital]

fixed that transform issue. Pooling tripped me up! #9819

[jakerdy]

Tested today with beta8. Memmory issue gone! And all other related to missing strokes and fills. Looks like all issues discussed here has been resolved. 🎉
Thank you very much!

[jakerdy]

New Graphics - Internal interconnections?

I don't know if there is some internal connection between different Graphics objects, but for some reason. One Graphics could mess up other Graphics which are completley unrelated to it.

In this example you could see that, node with text has black background (but it sohuld be brown), but after I connect other two nodes, it bacame brown as it should be.

More intrestingly code that draws snippet node, doesn't even rerun, so no, clear().rect().fill() touching that node's graphics. And there more examples like that when completley separate Graphics elements mess with each other.

I didn't changed my code structuraly I just adopt it to newer Graphics API like that:

[GoodBoyDigital]

this is an interesting one - they should certainly not depend on each other :D
But they use the same resources when being constructed, so that might be a thing! If you have a little example of this i could play around with that would be ace!

[jakerdy]

Pixi DevTools extension for Chrome

What works:

• Browse scene tree
• Change scene objects

What doesn't:

• Highlighting of selected elements in pixi viewport
• Tracing pixi elements by right click
• Text inspector has some missing parameters

[GoodBoyDigital]

This will need to be updated i believe - kind of surprised parts work :D

[GoodBoyDigital]

Hi!

I am happy to see that Pixi keeps evolving. I realy liked new way of creating object in unified way, especially Text.

I've been trying to port my app to v8. And now I have some difficulties with this process. I want to highlight this so that you could address it in future releases. Also if I mistakenly understand something, hope you will direct me.

All of this related to latest beta (8.0.0-beta6)

Thanks so much for such detailed feedback and questions! Will get back to you shortly 👍

[jakerdy]

Misc / Other

1. v7 DisplayObject (or containers) has property cullable, in v8 it disapeared. Does it mean that all scene object culled by default, or I should implement culling my self?

[GoodBoyDigital]

its on my todo :D right now there is no culling.
I would highly recommend culling at the application level vs relying on the renderer to do it as the overhead it introduced can affect perf (true for v7 as for v8!)

[jakerdy]

Ok, see your point. Going to implement it my self :)