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 authentication level.

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

Submitter:  Bastiaan Jacques <bjacques>
Submitted:  Tue 08 Jul 2008 09:04:59 PM UTC
   
 
Should Start On:  Mon 07 Jul 2008 10:00:00 PM UTC Should be Finished on:  Mon 07 Jul 2008 10:00:00 PM UTC
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  bjacques Percent Complete:  100%
Open/Closed:  Closed Effort:  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>
Group Member
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>
Group Member
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>
Group Member

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-08-07 bjacques StatusIn Progress Done
        Percent Complete90% 100%
        Open/ClosedOpen Closed
    2008-07-23 bjacques StatusNone In Progress
        Percent Complete70% 90%

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code