Re[2]: [Gnash] Gnash in embedded systems

[Udo Giacomozzi]

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