-
Notifications
You must be signed in to change notification settings - Fork 39
Support for Updating Rendering Options #34
Comments
If this lib adopted the use of PIXI.TextStyle lib, then I think most of your requests are covered. You see, you can create one PIXI.TextStyle instance, then give that to multiple PIXI.Text classes. Then, when you change the style, it emits an event that updates all of the text instances. In this libs case, 'default' would be a TextStyle, and any [keys] would also be a TextStyle |
Dave,
Thanks for your quick response. When the MultiStyleText is updated via the style property (the setStyle method has been deprecated), all style keys are removed/ignored with a default style from the Text class showing the markup that was given to the MultiStyleText’s style keys.
Anyways, I’ve submitted a request on GitHub for a change.
Arron
From: Dave Moore [mailto:[email protected]]
Sent: Wednesday, January 04, 2017 9:28 AM
To: tleunen/pixi-multistyle-text <[email protected]>
Cc: Arron Ferguson <[email protected]>; Author <[email protected]>
Subject: Re: [tleunen/pixi-multistyle-text] Support for Updating Rendering Options (#34)
If this lib adopted the use of PIXI.TextStyle lib, then I think most of your requests are covered. You see, you can create one PIXI.TextStyle instance, then give that to multiple PIXI.Text classes. Then, when you change the style, it emits an event that updates all of the text instances.
In this libs case, 'default' would be a TextStyle, and any [keys] would also be a TextStyle
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#34 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXxACeY8Dh5npztVOMYR_w589mhpEfznks5rO9aZgaJpZM4La1ok>.
|
This is something I've realized and considered in the past. This is messy mostly because the only style that's necessarily a full That said, we could do something similar to |
Looking again, I think I might've partially misidentified what you're trying to do. Note that you can update a let textStyles = {
default: { fontFamily: "sf_slapstick_comicregular", fontSize: fontSize + "px"},
first: { fill: "#e55c00"},
last: { fill: "#4fc1b7" }
};
let text = new MultiStyleText("<first>John</first> <last>Smith</last>", textStyles);
// ...
stage.addChild(text);
//...
fontSize += 10;
textStyles.default.fontSize = fontSize + "px";
text.styles = textStyles; That said, it'd also be nice to have We should probably also have an error or warning when trying to set |
Having said that, I do believe MST should internally copy the styles so changing them afterwards doesn't affect the rendering. But it also means we have to provide an easy way to change a style.
|
See c15a1fa for the ES6 approach to this issue. It works... surprisingly well. That said, I feel like dropping ES5 support is probably not the smartest move. Setting
let mst = new MultiStyleText("<tag>test</tag>", {
default: { fontFamily: "Arial" },
tag: { fontSize: "32px" }
};
stage.addChild(mst); // renders as expected
mst.styles.tag.fontSize = "64px"; // still has font size 32px
mst.text = "<tag>what?</tag>"; // now has font size 64px So if we want to allow read access to |
This I tried:
But unfortunately it doesn't change the text object.
That actually sounds pretty good to me. It would be a nice interface addition IMO. |
PR filed: #35. |
Awesome, thank you! |
Not an issue but a request for a feature really.
If a developer wants to support updating rendering options (e.g., change font size) for when the web browser is resized by the end-user, the developer has to remove the text component from the PIXI container and re-add it. If there are many MultiStyleText objects on the screen, this can increase the code base and development time. The performance of doing a resize can also be affected as well.
So after the user creates the text object and adds it to a PIXI container:
It would be practical to later be able to say (for example):
This would keep all other style keys still intact with only changes to the current style.
One other thought ...
Don't know how much extra work this would be but if the properties within each style key are set to dictionaries already (so a dictionary of dictionaries), a developer could simply override whichever interested property/properties they wish to choose:
This would only override the font size in the default style key.
The text was updated successfully, but these errors were encountered: