Re[2]: [Gnash-commit] gnash ChangeLog backend/render_handler.h backen...

[Udo Giacomozzi]

Hello Bastiaan,

Tuesday, October 24, 2006, 2:45:43 PM, you wrote:
>> Also, my
>> implementation does not require that the renderer to do perfect
>> clipping.

BJ> I don't understand how a Gui could do a better job at clipping than the
BJ> renderer. Nor do I understand how my commit changes the situation.

Ok, the current design allows that a renderer does clipping even when
the GUI does not know about clipping. Let's say the AGG renderer can't
do (or decides not to do) a perfect clipping in a certain situation
and overwrites the area /outside/ the clipping region. When the GUI
then updates the /complete/ window, then this garbage will become
visible.

With set_invalidated_region() the GUI tells the renderer which region
it is /interested/ in. Everything outside that region is undefined.

That's why either both GUI and renderer should support clipping or no
clipping should be done at all. Thus, by forcing the GUI to activate
clipping we can ensure this.


>>  In the case of AGG, it's even a bad idea because clipping
>> happens at sub-pixel level and this may lead to unexpected results
>> (anti-aliasing pixels summing up and such) along the clipping
>> rectangle.

BJ> In this commit, I have moved the Gui-specific parts of
BJ> set_invalidated_region() into the relevant glues. So that accounts for
BJ> the anti-aliasing correction I think you are referring to.

It's not the +2 pixel anti-aliasing correction I'm talking about.

Another example: When the left Y-coordinate of the clipping box is 5.5
then pixel at Y-coordinates 5 and 4 might be changed as well. A fully
implemented GUI will ignore the change at Y coordinate 4 and this
pixel will be re-rendered completely in a following frame. A GUI that
does not support clipping however will show everything.

This might sound like a minimal, barely noticeable problem, but when
you draw a anti-aliased rectangle continuously at the same position
without erasing it first this will lead to "oversaturated" edges that
look like a aliased bresenham line.


BJ> On a sidenote, I have moved the clipping related Gui code into the
BJ> relevant glues, because interfacing with the renderer is a glue's job.

gtk.cpp directly speaks to the renderer (line 258):

  _renderer->set_invalidated_region(changed_bounds);

BJ> So that sounds like we should have something like this in
BJ> Gui::display():

if (this->>glueImplementsClipping()) {
BJ>   _renderer->set_invalidated_region(changed_bounds);
BJ> }


Could be a solution, but the GUI looses control over the coordinates.
For example, the 2 pixel correction is useless for renderers that
don't do anti-aliasing anyway. At the other side the GUI might wish
aligned coordinates (= aligned memcpy) to speed up double buffering.

That's why my implementation worked like this:

- gui.cpp tells the GUI implementation which area *must* be updated

- The GUI implementation can ignore this /hint/ and is allowed to
  enlarge the bounds

- The final bounds are passed to the renderer and only that portion of
  the screen is really updated.


It's probably a good idea to document this.

Do you understand now what I mean?

Greetings, :)
Udo