bugGnash - The GNU Flash player - Bugs: bug #23621, Fading balls

 
 

bug #23621: Fading balls

Submitted by:  Benjamin Wolsey <bwy>
Submitted on:  Tue 17 Jun 2008 05:17:13 PM UTC  
 
Category: rendererSeverity: 3 - Normal
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Bastiaan Jacques <bjacques>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 13 Jul 2008 03:39:49 AM UTC, comment #10:

This item was already fixed.

Zou Lunkai <zoulunkai>
Sun 22 Jun 2008 02:15:10 AM UTC, comment #9:

This bug item was due to bogus implementation of "m.invert()". It was not an accuracy problem, it was a bug. BTW, this bug should be fixed now.

> And I wonder if gnash::matrix has enough precision to maintain
> accuracy. Perhaps we should use a general purpose matrix for
> AGG.


I think the answer is dependent on the use cases.

(1)The integer matrix is accurate enough for the core. "general purpose matrix" is too accurate and uncompatible for the core.

(2)We might need a general matrix for the renderer and for supporting random transformation from external user's requests.

see explanation below:

> matrix m = fill_styles[fno].get_gradient_matrix();
> m.invert();
> matrix cm = fillstyle_matrix;
> cm.invert();


For matrix::invert(), a 16.16 fixed format should be enough in theory, since the calculation itself is closed in mathematics. "closed" means the result also follows into 16.16 fixed format. (Fine so far, this code means fecthing filling styles from the core, swf specific)

> m.concatenate(cm);


In theroy, matrix::concatenate() is not closed in mathematics, which means the result cann't be represented in another 16.16 fixed format. But according to my tests, being "accurate" here is wrong, which means we do need to truncate the final result of matrix::concatenate() to a 16.16 fixed format. And this is not a special case, cxform truncates the same way. (Fine so far, this code means get the final concatenated transformation matrix from the core, swf specific)

> m.concatenate(inv_stage_matrix);


Now, "truncation" here might not be expected here, since the stage_matrix in Gnash is not swf defined.

eg.
gnash -width 10000000 -height 10000000 input.swf
gnash -width 100.0000001 -height 100.000001 input.swf

This command would affect the stage_matrix in Gnash if I understand correctly. So if we want to maintain the accuracy for the user, we might need a general purpose matrix.

AGG(and all other renderers I guess) does have its own general purpose matrix. In agg, it's defined as agg::trans_affine. It's already used a lot in agg. We can convert the gnash::matrix to agg matrix whenever we needed and do the concatenation and invertion later when accuracy is required.

Zou Lunkai <zoulunkai>
Sat 21 Jun 2008 09:22:06 AM UTC, comment #8:

The AGG render uses gnash::matrix quite heavily. For gradients, the code would have to be changed to something like:

matrix m = fill_styles[fno].get_gradient_matrix();
m.invert();
matrix cm = fillstyle_matrix;
cm.invert();

m.concatenate(cm);
m.concatenate(inv_stage_matrix);

And I wonder if gnash::matrix has enough precision to maintain accuracy. Perhaps we should use a general purpose matrix for AGG. Zou, what do you think?

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Fri 20 Jun 2008 04:33:31 AM UTC, comment #7:

I think this regression should be fixed with fixing matrix::invert()(not so
sure because local source changed more than that). It's likely we may get
overflows with the old code in matrix::invert()(my fault).

But it would still be good if bjacques have time to cleanup the fill_style
class and related code in renderers.

Zou Lunkai <zoulunkai>
Fri 20 Jun 2008 03:57:22 AM UTC, comment #6:

I think this regression should be fixed with fixing matrix::invert()(not so sure because local source changed more than that). It's likely we may get overflows with the old code in matrix::invert()(my fault).

But it would still be good if bjacques have time to cleanup the fill_style class and related code in renderers.

Zou Lunkai <zoulunkai>
Fri 20 Jun 2008 02:10:25 AM UTC, comment #5:

I reviewed your patch, no special handling(re-interpreting) for the swf defined matrix, so it's generally good. Let renderers to interpret the swf matrix is obviously better, since different renderers have different mechanism for filling styles. The old code was only intended for OGL.

Question1:

- if (is_morph)
-{
- input_matrix.read(in); // <-------- [1]
- m = input_matrix;
- m.invert();
- pOther->m_gradient_matrix.concatenate(m);
-}

Note that you removed a read() function, is that correct?

I think agg could work the same way as cario do, but no idea about OGL.

Zou Lunkai <zoulunkai>
Thu 19 Jun 2008 10:24:56 PM UTC, comment #4:

I confirm that matrix accuracy is the source of this bug. In fill_style.cpp, we use gnash::matrix as if it were a general purpose matrix. This causes a precision loss.

The attached patch removes all gradient matrix transformations in fill_style, moving the transformations to the renderer specific matrix type. (The patch is only for Cairo.) With this patch, rendering is identical to the attached screenshot.

(file #15879)

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Thu 19 Jun 2008 10:40:16 AM UTC, comment #3:

This issue also occurs with OpenGL.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Thu 19 Jun 2008 06:57:32 AM UTC, comment #2:

Actually, that screenshot is from an older build. My Cairo build from today demonstrates the same problem.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Tue 17 Jun 2008 05:25:59 PM UTC, comment #1:

Another gradient issue in AGG, I think.

(file #15861)

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Tue 17 Jun 2008 05:17:13 PM UTC, original submission:

The little balls that show lives in curveball have been gradually fading. In 0.8.2 they are clearly blue or red. In CVS 2008-06-13 they are mucher paler, and in head they are completely white. Please help to get the balls back!

Benjamin Wolsey <bwy>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #15879:  gradient_mat.diff added by bjacques (4KiB - text/x-patch)
file #15861:  screenshot-cairo.png added by bjacques (39KiB - image/png - cairo rendering (presumably correct))

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by zoulunkai (Posted a comment)
  • -unavailable- added by bjacques (Updated the item)
  • -unavailable- added by bwy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 13 Jul 2008 03:39:49 AM UTCzoulunkaiStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Sun 22 Jun 2008 02:15:10 AM UTCzoulunkaiStatusConfirmed=>Ready For Test
    Thu 19 Jun 2008 10:24:56 PM UTCbjacquesAttached File-=>Added gradient_mat.diff, #15879
    Thu 19 Jun 2008 06:57:32 AM UTCbjacquesCategoryrender-agg=>renderer
      Assigned toudog=>bjacques
    Tue 17 Jun 2008 05:25:59 PM UTCbjacquesCategoryNone=>render-agg
      StatusNone=>Confirmed
      Assigned toNone=>udog
    Tue 17 Jun 2008 05:25:58 PM UTCbjacquesAttached File-=>Added screenshot-cairo.png, #15861

    Back to the top


    Powered by Savane 3.1-cleanup1