taskGnash - The GNU Flash player - Tasks: task #8388, Remove the concept of subshapes...

 
 

You are not allowed to post comments on this tracker with your current authentification level.

task #8388: Remove the concept of subshapes from gnash::path

Submitted by:  Bastiaan Jacques <bjacques>
Submitted on:  Tue 08 Jul 2008 09:04:59 PM UTC  
 
Should Start On: Mon 07 Jul 2008 10:00:00 PM UTCShould be Finished on: Mon 07 Jul 2008 10:00:00 PM UTC
Category: NonePriority: 5 - Normal
Status: DonePrivacy: Public
Percent Complete: 100%Assigned to: Bastiaan Jacques <bjacques>
Open/Closed: ClosedEffort: 0.00

Thu 10 Jul 2008 06:55:30 AM UTC, comment #4:

Actually, it's quite easy, because the start of a new subshape is indicated by SWF, so once a new subshape marker is encountered, we can add a new Shape to the vector.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Thu 10 Jul 2008 03:08:19 AM UTC, comment #3:

> Instead, every shape_character_def will have a vector of
> Shape|s. So the algorithm becomes:


So in your algorithm, every shape(even they are in the same definition tag) could be drawn separately, and shapes within the same definition tag won't affect each other ?

Then I guess you'll need to analysis the paths and group related paths to complete drawable shapes.

Zou Lunkai <zoulunkai>
Wed 09 Jul 2008 06:25:41 PM UTC, comment #2:

At least in theory, a SWF file can have several shape definition tags. One could consider each of those shapes.

However, Flash combines several distinguishable subshapes (you can also call them shapes if you prefer) in a single shape definition. That means that Flash will offer a new set of fill and line styles and drawing of the new subshape must take place after the previous subshape.

Currently, the Path::m_new_shape member determines whether or not a new subshape should be started by the renderer.

So your usual algorithm looks like...

for_each(path...) {
if (path.m_new_shape) {
draw_all_previous_paths();
}
accumulate(path);
}

This is because subshapes can overlap.

I am changing the system to just eliminate the subshapes altogether (because, indeed, they are confusing). Instead, every shape_character_def will have a vector of Shape|s. So the algorithm becomes:

for_each(shape...) {
draw_shape(shape);
}

Does that clarify things for you?

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Wed 09 Jul 2008 08:09:10 AM UTC, comment #1:

> Currently, path has a member which indicates whether or not
> the current path is the start of a new shape.


Is the flag used for indicating a new sub-shape or a new shape? What is the difference between a sub-shape and a shape in definition?

> This means that
> the renderer should draw all paths previous to the current
> path and the current and following paths should draw over the
> previous paths.


Sounds really inefficient.

> I'm changing this system by changing shape_character_def to
> maintain an array of subshapes instead.


This is what we have at the moment:

std::vector<Path> m_paths;

What is the difference between a subshape and a Path? There seems to be no subshapes defined in Gnash.

> That way, the renderer can just loop over the array when it
> needs to render, making the algorithms more natural.
> Additionally, in the future, we might just invoke the renderer
> once for every subshape, making the renderers even simpler.


Sounds clearer if it isn't the case at this moment.

Zou Lunkai <zoulunkai>
Tue 08 Jul 2008 09:04:59 PM UTC, original submission:

Currently, path has a member which indicates whether or not the current path is the start of a new shape. This means that the renderer should draw all paths previous to the current path and the current and following paths should draw over the previous paths.

This is a cumbersome way of separating subshapes. Obviously the renderer needs to be aware of this path flag, making drawing algorithms more complex. In fact, almost every algorithm touching paths becomes more complex.

I'm changing this system by changing shape_character_def to maintain an array of subshapes instead. That way, the renderer can just loop over the array when it needs to render, making the algorithms more natural. Additionally, in the future, we might just invoke the renderer once for every subshape, making the renderers even simpler.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.

 

No files currently attached

 

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 (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 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 07 Aug 2013 07:15:39 PM UTCbjacquesStatusIn Progress=>Done
      Percent Complete90%=>100%
      Open/ClosedOpen=>Closed
    Wed 23 Jul 2008 09:03:54 PM UTCbjacquesStatusNone=>In Progress
      Percent Complete70%=>90%

    Back to the top


    Powered by Savane 3.1-cleanup