Re: [Gnash-dev] enable-engine
I fixed this : 1) Add a --with-mp3-decoder replacing the missing --enable-engine 2) Add some checks on its use (only valid with --enable-sound=sdl) 3) replace HAVE_MAD and HAVE_FFMPEG with USE_FFMPEG_ENGINE and USE_MAD_ENGINE --strk; On Tue, Oct 10, 2006 at 10:04:11AM +0200, strk wrote: Rob, can't find a commit-log of your --enable-mad = --enable-engine=mad change to answer there. Anyway, here's the problem: backend/Makefile.am:93: HAVE_MAD does not appear in AM_CONDITIONAL gui/Makefile.am:127: USE_FFMPEG_ENGINE does not appear in AM_CONDITIONAL gui/Makefile.am:132: USE_MAD_ENGINE does not appear in AM_CONDITIONAL utilities/Makefile.am:53: USE_FFMPEG_ENGINE does not appear in AM_CONDITIONAL utilities/Makefile.am:58: USE_MAD_ENGINE does not appear in AM_CONDITIONAL Also, I can't find --enable-engine handling anywhere (a pending commit?). Finally, would it be wiser to name that flag --with-mp3-decoder=XXX ? --strk; ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: gnash-commit subscription
Hello Rob, Monday, October 9, 2006, 5:00:03 PM, you wrote: How can I tell CVS which e-mail address to use in the From: field? RS It's probably safest to us the email account on savannah used to RS become a member of Gnash, which should then forward all email to your RS regular account. I was just discarding all non-member email. I just RS turned that off, and I'll hopefully see what the problem is next time. Have you changed the settings again? My commit mails do not show up anymore... Udo ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: agg.m4
On Mon, Oct 09, 2006 at 03:05:36PM -0600, Rob Savoye wrote:
strk wrote:
It seems that the current use of AC_CHECK_LIB in agg.m4 is broken.
We can't use agg::function checks as the compiler used to build
is gcc, not g++:
I just checked in a fix for this by PUSHing C++ as the configure
language to use when running that test. It works here to correctly find
the C++ symbol in the library.
mmm.. no luck here, doesnt' recognize the forward declaration:
configure:27958: checking for agg::gamma_ctrl_impl::calc_points in -lagg
configure:27988: g++ -o conftest -g -O2 -Wall conftest.cc -lagg -lrt -lX11 -l
Xi -lm 5
conftest.cc:60: error: 'agg' has not been declared
conftest.cc: In function 'int main()':
conftest.cc:64: error: 'agg' has not been declared
configure:27994: $? = 1
configure: failed program was:
| #ifdef __cplusplus
| extern C
| #endif
| /* We use char because int might match the return type of a gcc2
|builtin and then its argument prototype would still apply. */
60 | char agg::gamma_ctrl_impl::calc_points ();
| int
| main ()
| {
64 | agg::gamma_ctrl_impl::calc_points ();
| ;
| return 0;
| }
--strk;
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: gnash-commit subscription
On Tue, Oct 10, 2006 at 11:13:01AM +0200, Udo Giacomozzi wrote: Hello Rob, Monday, October 9, 2006, 5:00:03 PM, you wrote: How can I tell CVS which e-mail address to use in the From: field? RS It's probably safest to us the email account on savannah used to RS become a member of Gnash, which should then forward all email to your RS regular account. I was just discarding all non-member email. I just RS turned that off, and I'll hopefully see what the problem is next time. Have you changed the settings again? My commit mails do not show up anymore... Beside that, could you please always also commit an entry in the ChangeLog file ? --strk; ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re[2]: [Gnash-dev] Re: gnash-commit subscription
Hello strk, Tuesday, October 10, 2006, 11:18:17 AM, you wrote: s Beside that, could you please always also commit an entry in s the ChangeLog file ? I try to not forget that, yes. The last commits (today) belong to the same change, so only one entry in ChangeLog. Udo ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] GTK-AGG GUI
Hello, I've finished the implementation of the GTK GUI with AGG backend. Since I needed to make some modifications in gtk.cpp (more detailed description below) I wanted to check if this didn't break anything in the cairo implementation. I've found out that almost all flash movies, even the simplest ones, doesn't get rendered properly with cairo. I did then a fresh checkout of the current CVS code and tried that, but the problem remains the same. So it seems the cairo backend is already broken in CVS. Can anyone confirm this? The GTK-AGG GUI so far works perfectly. Except that the window resizing acts strange, but this is a known issue, isn't it? As mentioned I had to modify a bit the code in gtk.cpp. There is a GtkGui::init and a GtkGui::createWindow function. Basically the whole initialization is done in GtkGui::init, also the window creation. The problem with this is, that init is called before the swf movie is read, so the movie size is unknown during the window and renderer creation in init(). As AGG needs to know width/height I moved all the code for the creation of the window and the renderer to the createWindow() function. What I've seen there should be no problem, but is there a reason why this code was put into init() and could it break something if we move it from there? Hannes ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] GTK-AGG GUI
On Tue, Oct 10, 2006 at 01:03:36PM +0200, Hannes Mayr wrote: The GTK-AGG GUI so far works perfectly. Except that the window resizing acts strange, but this is a known issue, isn't it? I think I fixed this in current CVS, but you need to tell me more about the 'strangeness'. As mentioned I had to modify a bit the code in gtk.cpp. There is a GtkGui::init and a GtkGui::createWindow function. Basically the whole initialization is done in GtkGui::init, also the window creation. The problem with this is, that init is called before the swf movie is read, so the movie size is unknown during the window and renderer creation in init(). As AGG needs to know width/height I moved all the code for the creation of the window and the renderer to the createWindow() function. What I've seen there should be no problem, but is there a reason why this code was put into init() and could it break something if we move it from there? IIRC some renderers needed the window to exist before they could be created. I think cairo is one of these. A solution might be to encode these changes into the GtkGlue stuff. Gui interfaces still need some cleanups. I suggest you just commit your changes and we all check what breaks. Martin's setup seems an excellent resource here :) --strk; ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] does _height work??
Hi,
I just noticed that the implementation of
generic_character::get_height() seems to be wrong:
virtual float get_height()
{
matrix m = get_world_matrix();
float h = m_def-get_height_local() * m.m_[1][1];
return h;
}
virtual float get_width()
{
matrix m = get_world_matrix();
float w = m_def-get_width_local() * m.m_[0][0];
return w;
}
m.m_[x][1] is the rotation and m.m_[x][0] is the scale. So, in theory
get_width() should work as expected but get_height() should return a
wrong value.
Had no time to check this myself. Reading _height in ActionScript
should return a wrong value.
Can somebody check this, please?
Udo
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: agg.m4
strk wrote: On Mon, Oct 09, 2006 at 03:05:36PM -0600, Rob Savoye wrote: mmm.. no luck here, doesnt' recognize the forward declaration: You must be on an old compiler. What does gcc -v say ? It works just fine with gcc 4.x on FC5. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re[2]: [Gnash-dev] Re: gnash-commit subscription
Hello Rob, Tuesday, October 10, 2006, 4:54:26 PM, you wrote: Have you changed the settings again? My commit mails do not show up anymore... RS Nope, I haven't changed anything. Hmm, I don't know about others but I haven't received a single mail from gnash-commit today even if there have been several CVS commits. Udo PS: today means since 17 hours in my timezone ;) ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: gnash-commit subscription
On Tue, Oct 10, 2006 at 04:58:44PM +0200, Udo Giacomozzi wrote: Hmm, I don't know about others but I haven't received a single mail from gnash-commit today even if there have been several CVS commits. Confirmed (same TZ, btw) --strk; ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: agg.m4
On Tue, Oct 10, 2006 at 08:55:34AM -0600, Rob Savoye wrote: strk wrote: On Mon, Oct 09, 2006 at 03:05:36PM -0600, Rob Savoye wrote: mmm.. no luck here, doesnt' recognize the forward declaration: You must be on an old compiler. What does gcc -v say ? It works just fine with gcc 4.x on FC5. gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) Maybe it takes an explicit AC_TRY_RUN ? --strk; ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: agg.m4
strk wrote: Maybe it takes an explicit AC_TRY_RUN ? It shouldn't be necessary, and the test works like it's supposed to on my Fedora Core 5 and Ubuntu systems. I'm curious as hell why it's broken for you. You should get the proper value for the AGG headers, as if this test fails, it should go through checking all the hardcoded directories in the list. Does that step also fail for you ? - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] does _height work??
There seems to be another similar use in fontlib.cpp:502
// Transform the coords.
float x_scale = s_render_matrix.m_[0][0];
float y_scale = s_render_matrix.m_[1][1];
float x_offset = s_render_matrix.m_[0][2];
float y_offset = s_render_matrix.m_[1][2]
--strk;
On Tue, Oct 10, 2006 at 04:18:06PM +0200, Udo Giacomozzi wrote:
Hi,
I just noticed that the implementation of
generic_character::get_height() seems to be wrong:
virtual float get_height()
{
matrix m = get_world_matrix();
float h = m_def-get_height_local() * m.m_[1][1];
return h;
}
virtual float get_width()
{
matrix m = get_world_matrix();
float w = m_def-get_width_local() * m.m_[0][0];
return w;
}
m.m_[x][1] is the rotation and m.m_[x][0] is the scale. So, in theory
get_width() should work as expected but get_height() should return a
wrong value.
Had no time to check this myself. Reading _height in ActionScript
should return a wrong value.
Can somebody check this, please?
Udo
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
--
/\ASCII Ribbon Campaign
\ /Respect for low technology.
X Keep e-mail messages readable by any computer system.
/ \Keep it ASCII.
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re[2]: [Gnash-dev] does _height work??
Hello strk, Tuesday, October 10, 2006, 5:59:17 PM, you wrote: s There seems to be another similar use in fontlib.cpp:502 s // Transform the coords. s float x_scale = s_render_matrix.m_[0][0]; s float y_scale = s_render_matrix.m_[1][1]; s float x_offset = s_render_matrix.m_[0][2]; s float y_offset = s_render_matrix.m_[1][2] Indeed, that should be float y_scale = s_render_matrix.m_[1][0]; see http://www.gnu.org/software/gnash/manual/doxygen/classgnash_1_1matrix.html#7ed435e07b0d32ff7349bc157da3b5f5 Strange, this should produce dramatically wrong results!? Udo ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] GTK-AGG GUI
Hannes Mayr wrote: strk wrote: IIRC some renderers needed the window to exist before they could be created. I think cairo is one of these. The window and the renderer are created in the same function, so this shouldn't be a problem anymore. Ok, I take back my last statement... I found this nice comment in Player.cpp where Gui::Init is called: // Initialize gui (we need argc/argv for this) // note that this will also initialize the renderer // which is *required* during movie loading _gui-init(argc, argv); Any comments on this if in the current code the renderer is still needed during movie loading? IIRC some time ago there was a discussion about render calls while parsing. Is this still up-to-date or were there some changes in the meantime? If it's absolute necessary to have the renderer created before the parser starts it could be a solution to have an extra function to retrieve the movie size, so the renderer and the gui already know about the initial movie size. For example: get_movie_size(width,height) _gui-init(argc, argv, width, height) load_movie() Hannes ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] GTK-AGG GUI
On Tue, Oct 10, 2006 at 06:30:05PM +0200, Hannes Mayr wrote: Hannes Mayr wrote: strk wrote: IIRC some renderers needed the window to exist before they could be created. I think cairo is one of these. The window and the renderer are created in the same function, so this shouldn't be a problem anymore. Ok, I take back my last statement... I found this nice comment in Player.cpp where Gui::Init is called: // Initialize gui (we need argc/argv for this) // note that this will also initialize the renderer // which is *required* during movie loading _gui-init(argc, argv); Any comments on this if in the current code the renderer is still needed during movie loading? IIRC some time ago there was a discussion about render calls while parsing. Is this still up-to-date or were there some changes in the meantime? Unfortunately this is still an issue. We all hope Udo will help finally removing renderer calls during parsing by using an on-display caching mechanism. So far, the renderer is used to generate bitmap caches. If it's absolute necessary to have the renderer created before the parser starts it could be a solution to have an extra function to retrieve the movie size, so the renderer and the gui already know about the initial movie size. For example: get_movie_size(width,height) _gui-init(argc, argv, width, height) load_movie() This was the original implementation, but since we are usually getting the movie from a stream, it was simpler to avoid calls to that get_movie_info functions, which would have triggered a separate stream creation (that often mean an additional tcp socket + a zlib decompression) --strk; ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re[2]: [Gnash-dev] GTK-AGG GUI
Hello strk, Tuesday, October 10, 2006, 6:37:54 PM, you wrote: s Unfortunately this is still an issue. s We all hope Udo will help finally removing renderer calls during s parsing by using an on-display caching mechanism. s So far, the renderer is used to generate bitmap caches. As said before this is not the way to go IMHO. At least the create_bitmap_ methods should be allowed to be called at parse time because they are also required to translate bitmaps in a format suitable for the renderer. This *could* be done at play time but that would mean waste of memory because the raw bitmap from the SWF file is kept in memory until it is shown the first time. Even if the cached version (which is generated in the moment it is required) *replaces* the original bitmap data we still waste memory for sub-24 bpp modes. I will analyze the problem as soon I have some time left for it. There must be a different solution... If it is just for the stage size we could split renderer initialisation in two parts. First the renderer is initialized so that at least the create_bitmap_xxx functions are available (before parsing). Then, with an additional call the renderer is fully initialized with the stage size (during/after parsing). Would this be a solution? I currently don't know the exact details of the problem... Udo ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] does _height work??
On Tue, Oct 10, 2006 at 06:16:53PM +0200, Udo Giacomozzi wrote: Indeed, that should be float y_scale = s_render_matrix.m_[1][0]; Strange, this should produce dramatically wrong results!? I'm not sure, transformation matrices still don't fit in my brain. ... working toward producing some testcases for it ... --strk; ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re[2]: [Gnash-dev] does _height work??
Hello strk, Tuesday, October 10, 2006, 7:15:53 PM, you wrote: s I'm not sure, transformation matrices still don't fit in my brain. s ... working toward producing some testcases for it ... The matrix looks like this: |scale_x rotate_x translate_x| |scale_y rotate_y translate_y| Scale modifies the size of a object. Rotate rotates the coordinate around the object's anchor point. Translate defines it's position. So, taking the rotation field instead of the scale field should lead to odd heights. For rotate_y==0 (normal rotation) it should even become invisible or at least reduced to a horizontal line (as if scale_y==0). Udo ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: Re[2]: [Gnash-dev] does _height work??
s // Transform the coords. s float x_scale = s_render_matrix.m_[0][0]; s float y_scale = s_render_matrix.m_[1][1]; s float x_offset = s_render_matrix.m_[0][2]; s float y_offset = s_render_matrix.m_[1][2] Whoa, hang on, that code is correct. The matrix looks like this: |scale_x rotate_x translate_x| |scale_y rotate_y translate_y| Er, not quite. Try: |scale_x x_dep_y translate_x| |y_dep_x scale_y translate_y| Scale modifies the size of a object. Rotate rotates the coordinate around the object's anchor point. Translate defines it's position. It's worse than that :) the first two pairs of numbers define scaling and rotation between them. It's kinda hard to explain without a blackboard and a voice but here goes... Those 6 terms are actually the top two rows of a 3x3 matrix whose bottom row is (0 0 1), which lets you define any combination of scaling, motion and rotation (including flipping) in just 6 numbers. Better yet, the same distortion is always represented by the same set of 6 numbers. You take (x y 1) , multiply it by the transformation matrix and get (new_x new_y 1) In code, the transformation would be: (x * scale_x + y * x_dep_y + 1 * translate_x) is your new x (x * y_dep_x + y * scale_x + 1 * translate_y) is your new y and if you want to do the bottom row too, it's (x*0+y*0+1*1)=1 That may seem absurdly complicated but it lets you separate your object coordinates (x and y) from the transformation that is being performed on them. Once you have done that, you can say things like apply this transformation to every object in this group, you can take two or more transformations that need to be applied to objects in a scene one after the other and multiply the matrices together to obtain a matrix that performs all those transforms in one go, and there are functions that, given a transformation matrix will give you the matrix for the exact opposite transformation to map points back from the output to where they came from in the original object and so on. The values on the diagonal from top left to bottom right *do* scale the image if all the other values are 0, but so do the values at [0][1] and [1][0] as well as applying a rotation. I've called them x_dep_y and y_dep_x because they are how the output x coordinate depends on the input y coordinate and vice versa. Here are a few examples. It they're not obvious, try putting a few coordinates through the above formulae and see where x and y end up: 1. do nothing. the output is the same as the input: (1 0 0) (0 1 0) (0 0 1) 2. swap the x and y values over (flip it about the 45 degree line where x==y) (0 1 0) (1 0 0) (0 0 1) 3. rotate the figure 90 degrees anticlockwise about (0,0) (0 -1 0) (1 0 0) (0 0 1) ...the new y is the old x, and the new x is minus the old y. rotate the figure 90 degrees about 0,0 and blow it up to twice its size (0 -2 0) (2 0 0) (0 0 1) Now, suppose you want to rotate a square that is at (0,0) (0,100) (100,100) (100,0) about its centre. You can rotate it with matrix 2 above, but you'd need to shift it back 100 units right to get it back where it was, so that would be: (0 -1 100) (1 0 0) (0 0 1) Or, more precisely,the effect of this matrix is to rotate any object 90 degrees anticlockwise about the position (50,50). That-s all pretty counter-intuitive, I realise, but once you close your eyes to what's actually *in* the matrix, things become easy. It only gets tricky when you have to pick values out of the matrices and apply them to x and y values to actually perform the transforms. Does that make any sense? M ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Major changes in macros/
Hi, I've been adding and extending support for pkg-config in the m4-macros, as a step forward portability and the 0.7.2. One major change that is important is the one in boost.m4. Now it checks for the headers (heavliy STL-based stuff) only since the libs are unneccessary for the functions that we use, just a functions really needs the boost*-mt libs, like Date. However this enabled portability to the OpenBSD platform without any fuss... Over and out, Markus signature.asc Description: OpenPGP digital signature ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
