On Aug 22, 2:22 am, Johann Horvat <[EMAIL PROTECTED]> wrote: > Dear mozilla people, > > We are developing an application, which display dynamic html-content on a > digital sinage screen. > > What will have to be done are the following steps: > > 1. Get the content to be displayed (pure html with little css) > 2. Render the content to a 720x576 buffer (rgb or argb) > 3. Memcopy this buffer to the SDI card. > > Is Gecko / Mozilla a possible solution for us? Would it be fast enough to > render something like this - 25 times a second???: > > ---------START HERE---------- > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > <html> > <head> > <meta content="text/html; charset=ISO-8859-1" > http-equiv="content-type"> > <title></title> > </head> > <body> > <big><big>13:56 > > Weather: cloudy<br> > <small style="font-family: Helvetica,Arial,sans-serif;">This > is a demonstration string...</small></big></big> > </body> > </html> > ----------END HERE----------- > > In our case embedding would mean: > 1. Only use html/css rendering features - to keep it simple and small > 2. The faster it renders, the better it is > 3. The application shall not show a browser window, but render a buffer > containing the rendered content. > > Do you have any suggestions/ideas? > Any comments welcome! > > Best regards and thank you > Johann > -- > View this message in > context:http://www.nabble.com/Using-Gecko-Mozilla-for-rendering-html-content-... > Sent from the Mozilla - Embedding mailing list archive at Nabble.com.
Dear Johann, The desire to use the Mozilla engine to render to a buffer has been around for several years, and for many applications. However, addressing what appears to be a pressing need has not been a priority (perhaps understandably, given the size of the Firefox market). Even the projects that begin to move in that direction seem to bring in a lot of big dependencies (up to the whole X window system), where what is needed is just the capabilities you describe. There are some good technical reasons for this, such as the use of system installed fonts, and the absolutely incredible size and complexity of the Mozilla code base, but there are many that believe it should be possible (but they have not actually done it). There are some interesting projects, like the 3D browser project (that is the reference that callum points to), that do effectively render to a buffer, then manipulate the buffer before it is actually displayed. For those that must use Mozilla to render to a buffer, the most successful approach (perhaps the only working approach) is to run the browser on a screen that is not displayed. This can be done easily under Linux with additional X displays, and can be done under Windows using virtual displays (but last time I checked there were no public display drivers, everyone builds their own based on Microsoft's framebuffer examples). The desired data is then copied from the non- visible display, and you can do whatever you like with it (including sending it to a non-system-supported display in some proprietary format). As you might expect, this approach incurs absolutely huge overhead. Even if only html/css is used, and tempting features like Flash etc. are avoided, if css is used to any extent (fonts, layers, backgrounds, etc.) then there is lots of processing. Also, where elements are normally rendered directly to some hardware display buffer, often using some hardware acceleration if the driver includes it, here everything is being rendered to system RAM with no acceleration. If that were not slow enough, the resulting amount of data in the buffer is also very large, and taking a snapshot of it by copying it somewhere else to work on (or send) is also slow. You can get a quick idea of the amounts of data you'd be moving by looking at your frame rate (say 30 fps) times the X times Y size of your buffer times your color depth (often four bytes per pixel for performance reasons four byte boundaries are as good or better than something smaller). Unless you have a very fast machine, or small display size, you just can't move that much data and have processing power left for much else. The best rates I have seen using this approach with a small size (640 x 480) are around 2 or 3 frames per second - a long way from your target. The final challenge is that because this is a non-standard use of the Mozilla browser, controller the browser (or renderer as you would like to have it) itself is extremely problematic, depending on what you are doing. If it is displaying conventional web pages, that can be OK, but if you want control over navigation, and the ability to arbitrarily force Mozilla to render something when you want, then it is a surprisingly big headache. The documentation obviously is not geared toward the use of the browser to render, and many of the events don't work in the way you might expect based on the documentation that is available. Beyond that, non standard use of the events etc. seems to produce crashes and/or memory leaks, and where these are vary depending on the target operating system (Windows or Linux). Depending on what and how often you are rendering, there are still memory leak issues with Firefox/Mozilla that can cause the memory image to grow fairly quickly to 100 MB or more. More fps would accelerate any memory loss, perhaps dramatically. It seems there has been some progress with uBrowser (now really LLMozLib) since I last had a chance to try it out, so it is definitely worth looking at. However, you may need to look for some non-Mozilla alternative. I have looked extensively in the past, and could not find anything suitable, and ended up on Mozilla anyway (and increasing machine power and cost, decreasing performance, and using periodic automatic restarts to deal with memory and crash issues). Or if you or your company is brilliant and community-minded, you could be the savior that finally creates what is so desperately needed - maybe starting with the Gecko code base? All the best, J _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
