gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Re: Font antialiasing (was: GTK-AGG GUI)


From: strk
Subject: [Gnash-dev] Re: Font antialiasing (was: GTK-AGG GUI)
Date: Thu, 12 Oct 2006 12:41:07 +0200

On Thu, Oct 12, 2006 at 09:08:39AM +0200, Udo Giacomozzi wrote:
> Hello strk,
> 
> Wednesday, October 11, 2006, 11:25:01 PM, you wrote:
> s> This can be a solution for the 'renderer' availability during
> s> parse time, anyway this was already fixed by all but GTK/AGG
> s> combination.
> 
> Oh. Missed that. How was it fixed?

For the cairo backend, which also needs size to be specified,
the render_handler_cairo exposes an additional function to
set the drawable. Can we do something similar for the AGG
backend ? Splitting movie_def_impl creation from actual 
firing of the "loader" thread would require modification of
the create_library_movie and create_movie and friends, which
would be a not-so-trivial change.


> s> The other problem we have, and that persist with all renderers
> s> (what we call 'font antialiasing'), is the current implementaion
> s> of fonts glyph rendering. It relies on the fact that the whole
> s> SWF has been parsed before rendering the textured glyphs.
> s> It must be modified to allow on-demand rendering of them,
> s> or, if you prefer, right-after-reading-definition rendering
> s> of each font.
> 
> I understand. I'd say on-demand rendering should be a nice solution.
> Tthat way we keep all rendering calls in one thread, right?

Right. Anyway, for the short-term problem (font antialiasing)
right-after-reading-definition would be good enough.

> I think I can do it, but I'm very busy at the moment, so if anyone
> else wants to do it, no problem ;)

I think you're in the best position to take this task... we can probably
wait until you have more time :)

--strk;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]