gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] bounds_in_clipping_area bug


From: Udo Giacomozzi
Subject: Re: [Gnash-dev] bounds_in_clipping_area bug
Date: Fri, 8 Feb 2008 17:22:22 +0100

Hello strk,

Friday, February 8, 2008, 3:51:36 PM, you wrote:
s> The bounds passed to the function are the "invalidated" bounds
s> of a sprite,

Wrong. The add_invalidated_bounds() call has the "force" flag set, in
which case it will always return the complete bounds of the sprite,
not just the invalidated ones.

s> in my case being "NULL".

Odd. That would mean that the sprite does not contain any visible
elements.


s> Now, a couple of issues:

s>  1) The View->Redraw menu item (available in GTK) should
s>     force redraw of everything, specifically to avoid such
s>      invalidated-bounds related bugs

This should not be related with invalidated bounds, even if some
functions are used which primary use is for invalidated bounds. The
display() method just uses the function to detect the bounds of it's
childs (even if they did not invalidate). The goal is to stop
descending the display list elements if the sprite is outside the
stage or the currently rendered part of it. "Redraw" will set the
clipping area of the renderer to the window and thus everything will
be re-rendered.


s>  2) I don't understand that call at all, as it doesn' use
s>     the old_invalidated_bounds at all, nor it uses a normal getBounds.
s>     Udo, can you shed a light on it ?

I don't see any reason for old_invalidated_bounds. We just want to
find out where the sprite is visible, not where it has been before.
For example, when a sprite moves in from outside the stage to the
middle of it, we just care about it's new position, which probably is
now inside the clipping area.

Again, this has nothing to do with invalidation, this is just a check
whether the sprite is inside the clipping area of the renderer.

getBounds() is similar, but returns only one single range. Consider
this situation:


  +-------window----------------------------------------------+
  |                                                           |
  |   #######                                       #######   |
  |   #######                                       #######   |
  |   #######     +--clipping area-----------+      #######   |
  |               |                          |                |
  |               |                          |                |
  |               +--------------------------+                |
  |                                                           |
  |                                                           |
  |   #######                                       #######   |
  |   #######                                       #######   |
  |   #######                                       #######   |
  |                                                           |
  +-----------------------------------------------------------+

Regardless of what vector passed to the renderer, it will *always*
discard (not change) any pixels outside the clipping area. The sprite
has four childs (marked with "#") which are all outside the clipping
area.
getBounds() would return an area that includes the clipping area, even
if no part of the sprite (it's childs) is included in the clipping
area.
add_invalidated_bounds() however would return four bounds, one for
each child and none of this bounds intersect with the clipping area,
so display() will stop wasting time.

Please don't mix up the "clipping area" with the "invalidated bounds
area". In many situations these will be the same, but the GUI still
has the last word deciding the clipping area.


Now, I hope you understand the principle behind that code. To add one
more: I actually doubt that code is much useful. This is much work
(add_invalidated_bounds is not just a quick lookup) just to avoid
recursive display() calls. Instead, it would be better to do the check
in generic_character, where it would be done only once.

The current design re-calculates and checks the bounds for each
recursion level, which is suboptimal.


s> To reproduce the bug, just make movie with no visible drawing
s> loading a movie with somethign in it.

s> Gnash will just always show a blank screen.

Does it render when you comment the "if bounds_in_clipping_area" line?

How does the display hierarchy look like in this case?


Udo





reply via email to

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