Re: [Gnash-dev] Questions about trapezoids, triangle stripper etc.

[strk]

On Mon, Oct 02, 2006 at 10:02:26AM +0200, Udo Giacomozzi wrote:
> Hello strk,
> 
> Wednesday, September 27, 2006, 2:50:43 PM, you wrote:
> s> Agree, let's pass some render-agnostic data to the renderers, not
> s> important to pass instances atm, just whatever is appropriate, but
> s> NOT requiring calls to the renderer during parsing.
> 
> I see a problem now. When loading bitmaps, a method
> (create_bitmap_info_rgb) in the render handler is called which must
> convert the RGB(A) buffer to some data structure the render can work
> with when drawing. Probably that method is called during parsing.

Yes, this is the issue. For all create_bitmap_info_*.

> Now, we *could* rewrite the code so that the bitmap is not
> pre-initialized and so that the renderer must use some sort of cache
> for the bitmap that gets initialized once. For example, calling itself
> create_bitmap_info_rgb() the first the the bitmap is required.

Right, this was the idea.

> However, this has two problems:
> - we waste memory since the original RGB(A) buffer is kept in memory
>   (add the cache and you need apx. twice the memory). Bitmaps use
>   *lots* of memory!
>   The renderer could instruct the character definition to remove the
>   original RGB(A) buffer, but I don't like this at all.

mm... what about keeping a placeholder in the parser and replace it
with the transformed one when the renderer needs so ?
For example: define_bitmap_character_def() would hold a bitmap_info
instance, which would basically just keep an image::rgba or image::rgb
member (maybe using two subclasses of bitmap_info...).
Then, the renderer, when passed a define_bitmap_character_def() would:
        - fetch the bitmap_info
        - verify if that's an instance of it's own structure
        - construct it's own (converted) bitmap_info ( again a subclass
          of bitmap_info) and put it back to define_bitmap_character_def()
          [ trough a set_bitmap_info() function, that would reset an auto_ptr ]

> - conversion is done at play time, which may slow down the playback at
>   single frames

Yep, this would reamain an issue.

> What's the problem with calling some renderer methods at during
> parsing, anyway?

Initially this was a threading issue, as the opengl backend would use
threads and those were messing the the loading/playing threads layout.
Now that problem seems fixed, but we tought it would still be nice 
to get a better separation between parser and playing so to be able
to use the parser in other applications.

Anyway, I'm no more that strongly convinced about it. I wouldn't give
away too much speed for this. I'd just make sure that caching during
parsing is something appropriate for the flash datamodel (thinking
about bitmap filters introduced in later SWF versions and bitmap
transforms). What do others think about this ?

--strk;