Re: [Gnash-dev] Drawing bitmaps (and documenting rendering calls)

[strk]

On Tue, Feb 13, 2007 at 01:24:31PM +0100, Udo Giacomozzi wrote:
> Hello strk,
> 
> Tuesday, February 13, 2007, 1:07:35 PM, you wrote:
> s> server/render.h - namespace is defined here, all calls proxied to global 
> render_handler
> s> backend/render_handler.h - base class for all render handlers
> 
> s> Where should we keep the official Doxygen documentation for them ?
> 
> Don't know. The render handler was rather confusing for me at first.
> What's the real use for it, anyway? AFAIK it handles calls when no
> render handler is yet initialised. Is there any other reason? And, is
> it still valid?

You're talking about the 'renderer *namespace*' here, right ?
I'm sure it's still used, and I've to say I also found a use
for it in the past (having all renderer calls trace a message
to detect rendering calls from parser).
Anyway, the functions in the namespace are simply proxes,
so my vote goes to documenting render_handler.h instead
and add comments in server/render.h sending the reader to
the other file for documentation.

> s> I need some documentation for the draw_bitmap() call as I'm
> s> implementing loading of external JPEGS.
> 
> draw_bitmap() is an old function that's AFAIK only used to draw
> bitmap-cached font glyphs. If you look closely you'll notice that the
> AGG renderer does not even implement this method.

I noticed that, now that I finally called the function.
OpenGL wasn't so kind, but still doesn't work..

> I don't know what you exactly mean by "loading of external JPEGS".
> Normally loading a .JPG file in Flash is like loading a .SWF file that
> contains nothing else than a bitmap at stage size. Isn't this already
> supported by Gnash?

No. See testsuite/misc-ming.all/loadMovie.swf (generated by Ming).
I'm working on this now, only missing piece is rendering.

> BTW, embedding a bitmap in a Flash movie technically means having a
> rectangle whose fill style is set to bitmap fill. There is no
> difference to an arbitrary shaped character with bitmap fill (ok,
> the latter will use wrapped fill mode, but that's another story).

Ok, this means I can't avoid producing the shape. Thanks for the info.
Maybe I won't even need size of bitmap_info then.


--strk;