Render HTML Text

[Beta_Ravener]

Hi,

 

is there any way to render text with HTML tags, such as <b>, <sup>, etc.? Or at least easy workaround?

If not, what and how would have to be implemented? I will need this functionality soon, so I would have to come up with some decent solution and some tips would be appreciated. I was thinking of something like letting some HTML element render the text, save it to bitmap and use this image instead of text, which is rather dirty and native way would be better, but dunno how hard it would be to pull off.

 

Thanks.

[MattMcFarland]

I dont think so, not out of the box per se.  However creating an library to acheive this could be made.  I am thinking of making one.

 

There is a library that does use xml tags and renders them in the canvas that I know of (their may be more) but I haven't used it.  It's called React-Canvas -> https://github.com/Flipboard/react-canvas

 

It basically renders React Components in the canvas (the use-case for this was that canvas redraw is way faster than DOM redraw) and React is where I'm getting the xml-tag speak from.   React basically uses xml like tags in javascript (actually a lot more than that, but I want to be brief) I hope this helps, or maybe someone might know of something even better!

[mattstyles]

Don't neglect that text can just be rendered the good old fashioned way, absolutely no problem using canvas elements with other elements in the page. Might not be an option depending on your use case though.

 

Other than that, yeah, whilst the transforming of styles is fairly trivial the positioning of text not so much, unless you're using a monospace font.

 

Using react and react-canvas is great, but, would probably require extensive changes to how you structure your application (although React is excellent, its a little heavy for games but for the right game using a React UI layer on top of all the heavy stuff is awesome-sauce), also, I'm not sure React-canvas is still actively developed, I'm also not sure Flipboard are still using it anywhere (hence the lack of dev).

 

To work out the positioning you'd either need to render each text snippet into an element using the same styling and measure the size, but this is not performant, better to calculate the size of each character for the font upfront by rendering each into a span and measuring that, keep track of it somewhere and that should help you solve any positioning woes. From memory, I think that is how React-canvas does, the code will be in a utility file somewhere (ages since I looked at it), but I've seen the theory in a couple of different places, and used it too. You'd have to test but I think if you do the size-rendering tests at 10px you should be able to scale up and down fairly easily too so no worries about changing font size.

[Beta_Ravener]

Great insight.. I would like to keep all logic in canvas, so I guess I'll go with the positioning.. Actually for now I would need only <sup> and <sub> tags I think, this could be maybe emulated by chopping the string into chunks and rendering then separately. Of course this won't work for multiline text but it might be just fine for my case. I was just wondering if the PIXI did implement it somehow before I start doing my own little library.

 

And I never worked with react so I can't imagine well how it would work together, but if you (Matt) could create a library easy to use and well integrated into PIXI, I would be happy to use it

[MattMcFarland]

I agree React might be overkill (depends on use-case of course)

 

Just want you to know that I am looking into this, I am very interested in adding HTML markup to the canvas.  If I make something, I want to make it compatible with both PIXI and Phaser (as I am actually playing around with both) - but the idea would be something that works with just about any canvas-drawing engine, in a perfect world that is.  

 

So the first thing I've found, which looks really promising, is this article: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Drawing_DOM_objects_into_a_canvas which shows how to draw DOM objects into a canvas.  I'm not sure what the caveats are and I havent tried it yet, but I think that's a good place to start

[d13]

Another strategy is just to create a new <div> HTML layer that sits on top of the Pixi canvas and is the exact same height and width.

You could then just create a few simple JavaScript functions like `uiText`, `uiButton`, and `uiImage` that write and update HTML tags on that layer.

Then create a few simple fade and tweening functions, and animate them inside your existing game loop.

[MattMcFarland]

Another strategy is just to create a new <div> HTML layer that sits on top of the Pixi canvas and is the exact same height and width.

You could then just create a few simple JavaScript functions like `uiText`, `uiButton`, and `uiImage` that write and update HTML tags on that layer.

Then create a few simple fade and tweening functions, and animate them inside your existing game loop.

 

Could work, but Im not sure how this affects browser reflows?  (need to confirm)

 

Also another worry is how DOM events bubble, how would it effect the canvas?  Wouldn't a clickable button prevent the click underneath it?  Maybe not in all browsers, but I've ran into issues with DOM objects blocking other objects in the past (I think with some version of firefox and with IE 10)

 

Another issue is different browsers apply layouts slightly different, would wonder how to keep things in the positions you need them?  

[d13]

Also another worry is how DOM events bubble, how would it effect the canvas?  Wouldn't a clickable button prevent the click underneath it?  Maybe not in all browsers, but I've ran into issues with DOM objects blocking other objects in the past (I think with some version of firefox and with IE 10)

 

Another issue is different browsers apply layouts slightly different, would wonder how to keep things in the positions you need them?  

Yes, I'm also not sure about the some of these details, we'll have to test it! 

[mattstyles]

Modern evergreen browsers will let you easily choose which elements steal clicks with the css property pointer-events.

 

If you're going down the route of using actual elements for what they are for, no need to overly complicate things with fade and tween animations, let css take the strain. Dont reinvent the wheel if you dont need to, 99% of the time between transitions and animations css will have you covered.

[Darker]

I strongly agree with mattstyles - I use normal HTML when rendering text and forms and stuff and I only use PIXI for actual game animation. I mean I wanna make a game, not reinvent HTML renderer - what do you want?

 

Not only yo have CSS, form elements but you can also use some framework like JQuery so that you can really concentrate on your game, not on centering stupid DIV element in the middle of the screen.

[MattMcFarland]

I agree 100% - no need to re-invent the wheel.  

 

It really depends on your requirements and what you want to accomplish, I think that rendering HTML overtop the canvas will work with plenty of use-cases.   I am not 100% sure if it is full proof across different viewport sizes.  I know media queries and browsers behave differently with DOM elements and sometimes positioning something in a pixel perfect place over-top the canvas can prove to be much more challenging than you originally thought. Another disadvantage to using the DOM is that it is horrendously slow.

 

However, if you have specific requirements to develop the game UI inside the canvas, and think, "hey that would be neat if I could render HTML elements inside my game" - well this is completely possible!  the link I shared up top proves it, you can use HTML/CSS and render it to svg and use the svg as a bitmap.  So it's possible.  Another thing is nodejs modules are plentyful and there are a few that will allow you to read a DOM pretty quickly.  So really there's not that much wheel-reinvention either way.

[mattstyles]

Another disadvantage to using the DOM is that it is horrendously slow.

 

 

Anyone reading this needs to be aware that this is essentially true (DOM manipulations are costly), but (and this is equally as true of JS), if something is perceived to be fast enough by the human user, then its fast enough.

 

For most use case, certainly for the case of displaying text, rendering a DOM fragment and changing its textual contents will be far far far faster than any human eye will ever be worried about, and this is usually true of just about any platform (even old ones) that you'll be firing that DOM through.

 

There are many games out there that use nothing but HTML elements and CSS and they are perfectly playable, to the point where you wouldnt know whether it was a canvas or DOM elements. The perception that this is has never been possible is born out by some poor JS animation libraries in popular circulation (yes, I'm looking at you jQuery and your shoddy animation routines, although you're not the only sinner), I wouldnt suggest trying to write a top-down space shooter with several hundred bullets firing around in pure DOM, but, I've written several particle emitters in pure DOM and even on cruddy old phones worked well enough.

 

There is also a wee bit of a framework war going on, Facebook claim that DOM is very slow leading to poor application performance so they create React (which amongst its many strengths limits DOM manipulations), Google fire back that its not the DOM that is the major bottleneck in most applications, so, its kind of ho-hum. 

 

Sorry for going off topic. It is at least good that we're getting lots of different concerns on this one.