Hi Strk, sorry for the late answer:
Thursday, July 6, 2006, 12:21:09 PM, you wrote: s> For non-accelerated hardware, Gnash is incredibly slow at the s> moment, but with some attention on the cairo backend this could be s> fixed. We're using GTK along with DirectFB at the moment (graphics chip is an external EPSON S1D15A04) and it *is* incredibly slow and resource intensive for that what it does. We had not much time for optimizations yet, however for that what it needs to to it's very slow (sometimes you can watch the GUI drawing the windows). I don't think the hardware is the bottleneck as previously I had a simple GUI working with a 1-bit graphics mode using a graphics display attached to a GPI/O port (5 ioctl operations to transmit 8 pixels). The graphics engine was written by me (remember 1 bit modes are difficult) in plain C and it was *much* faster. Anyway, as long as the GUI is reasonably responsive everything is OK. s> There is no milestone set at the moment, a consequence of funds s> shortage. Support for the project would surely help moving things s> forward quicker. Let me know if you're interested in this. Well, I can't decide this myself alone, I have to talk with my folks. Please note we're a very small company. Spending money for a good GUI is OK, but we have to weigh it up. Anyway, I would be interested in learning more about it. Our idea would be to allow other people to develop own projects with our hardware, so we would need a somewhat stable version in the near future. Flash 6 or at least Flash 5 support would be completely enough. Also I'm sure embedded applications are the second most important applications areas - right after Mozilla plugins - for Gnash. That would be the missing brick for consumer devices based on Linux. Macromedia has already recognised the demand for such solutions (no wonder that their Linux player plugin is not allowed to be used in embedded systems as they want to sell licences). [anti-aliasing] s> I'm not sure it currently supports that, but it's probably tight s> to the specific renderer in use. Implemented renderers are OpenGL s> and Cairo. I had a look at Cairo. It seems that it anti-aliasing is a fundamental aspect of it because it uses sub-pixel coordinates. How far is the Cairo implementation? I think OpenGL would be the wrong solution for a embedded system. >> Can the stand-alone player work without GTK (draw directly to the >> framebuffer, or via DirectFB)? If not, are there plans for that. s> There are plans for that, the new modular code (gui/) should be ready s> for that. Cairo can access framebuffer directly by itself, correct? I think I read in the documentation that you can draw to any in-memory buffer and the system framebuffer would fir into that. Thanks for your information, Udo _______________________________________________ Gnash mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash
