[bugs] Next/Prev button, feComposite, feGaussianBlur

[Vincent Hardy <vi...@eng.sun.com>]

While I was doing regression testing today, I found the following
problems:

a. Next/Prev button is screwed up. I think this is related to the
   white screen repaint problem, but I am not sure.

b. feComposite. I found that we do not pass the BE 
   filters-fldMrgOff-BE-15.svg as we should (we have all the filters 
   for it). Tracking it down, I think we simply inverse the sources
   compared to what the spec. says. The spec defines in / operation /
in2,
   and I think we are doing the reverse. Thomas, you may want to check
   it out (I have attached the BE to this email).

c. feGaussianBlur. When zooming in logoShadow.svg, then panning, 
   zooming again, etc..., edges of the tiles become visible and the
   result is sometimes blocky. 

V.

[bugs] Next/Prev button, feComposite, feGaussianBlur

[Thomas E Deweese <th...@kodak.com>]

>>>>> "VH" == Vincent Hardy <vi...@eng.sun.com> writes:

VH> While I was doing regression testing today, I found the following
VH> problems:

VH> a. Next/Prev button is screwed up. I think this is related to the
VH> white screen repaint problem, but I am not sure.

VH> b. feComposite. I found that we do not pass the BE
VH> filters-fldMrgOff-BE-15.svg as we should (we have all the filters
VH> for it). Tracking it down, I think we simply inverse the sources
VH> compared to what the spec. says. The spec defines in / operation /
VH> in2, and I think we are doing the reverse. Thomas, you may want to
VH> check it out (I have attached the BE to this email).

    You are correct I've fixed this locally and we now get the same
result as the png, except our font is significantly bolder than the
one in the PNG (so we run long...).

VH> c. feGaussianBlur. When zooming in logoShadow.svg, then panning,
VH> zooming again, etc..., edges of the tiles become visible and the
VH> result is sometimes blocky.

    I'll look into this, the blockyness isn't too surprising since
this uses filter-res 200x200.  However the tiling artifacts are pretty
severe in this case, I'll see what I can do to remove them...

Re: [bugs] Next/Prev button, feComposite, feGaussianBlur

[Bill Haneman <bi...@ireland.sun.com>]

Vincent Hardy wrote:

> The next/prev problem is that when I view several documents one after
> another and then try to use the prev and next buttons, 
<...>
> this is due to the
> fact that we only sometimes add urls to the history which causes this
> bad behavior. 

Thanks, now I know the issue.  I presume we want browser-like behavior
(typing into URL entry field produces "next" at current document
and prunes former history).

> About the flashing, it happens with or without the 'fixed size window'
> every time a new window is opened. For example, open index.svg and click
> on one of the links (e.g., opacity.svg). This opens a window, then the
> window resizes, then there is a black flash, then it paints.

My point was that it does not happen with forward and back if 
the documents have the same viewport size.

Now that I know what to look for, I can see it (albeit a little
less clearly) in linux.  However it happens with a batik build
from Oct29 also (before my changes to JSVGCanvas).  I will check to see
if
that's true on Windows as well.  As I said, I am nearly certain that
this is produced by a resize and pack() call on the canvas.  With
some effort we should be able to prevent this on initial startup at
least,
(but we have to call pack if we resize the canvas, of course).

By the way, I have been trying for 4 hours to commit my fixes,
I may or may not have done so (I keep getting disconnected by
apache.org so I cannot confirm whether the commit was actually
completed,
it takes 10-12 tries to get through at 10 minutes each :-(

-Bill

--------------
Bill Haneman
+1 353 1 849 0495

Re: [bugs] Next/Prev button, feComposite, feGaussianBlur

[Vincent Hardy <vi...@eng.sun.com>]

Bill,

The next/prev problem is that when I view several documents one after
another and then try to use the prev and next buttons, the viewer does
not take me back to what I perceive as the right document. Sometimes 
it skips one, sometimes not. From a user point of view, it is confusing. 
Scenario to reproduce the problem:

a. Start viewer with index.svg
b. Click on Next. Gets you to index2.svg.
c. In location bat type opacity.svg
d. Hit the 'prev' button. Get back to index.svg

Actually, now that I am typing all this, I realize this is due to the
fact that we only sometimes add urls to the history which causes this
bad behavior. I withdraw my comment that it may be related to the 
white screen.

About the flashing, it happens with or without the 'fixed size window'
every time a new window is opened. For example, open index.svg and click
on one of the links (e.g., opacity.svg). This opens a window, then the
window resizes, then there is a black flash, then it paints. 

V.
Bill Haneman wrote:
> 
> Vincent Hardy wrote:
> 
> > a. Next/Prev button is screwed up. I think this is related to the
> >    white screen repaint problem, but I am not sure.
> 
> I'll need more info, looks fine to me.  What's the problem?
> 
> BTW, the white screen repaint "problem" was a choice, sorry
> nobody liked it  :-\
> I was tired of looking at blank screens on linux and Solaris
> (ultra-1, 2.6). The performance on those 2 platforms is about
> an order of magnitude slower than on windows :-(
> I concede that there are strong arguments in favor of blanking the
> screen.
> 
> I have reinstated the screen blanking and setting of the
> document and root node to null on newload, will put the changes
> back today.
> 
> Also:  Would those of you complaining about "flashing" when switching
> documents please try turning "fixed size window" on and confirming that
> the problem goes away (as it does on my win98 box) ?  I believe that
> the flash is caused by a Swing invalidate()+pack() which has always
> been in the code, not sure why it's become more visible.  You
> might try changing your windows background color to reduce the
> severity.
> 
> -Bill
> --------------
> Bill Haneman
> +1 353 1 849 0495
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org

Re: [bugs] Next/Prev button, feComposite, feGaussianBlur

[Bill Haneman <bi...@ireland.sun.com>]

Vincent Hardy wrote:

> a. Next/Prev button is screwed up. I think this is related to the
>    white screen repaint problem, but I am not sure.

I'll need more info, looks fine to me.  What's the problem?

BTW, the white screen repaint "problem" was a choice, sorry
nobody liked it  :-\
I was tired of looking at blank screens on linux and Solaris 
(ultra-1, 2.6). The performance on those 2 platforms is about 
an order of magnitude slower than on windows :-(  
I concede that there are strong arguments in favor of blanking the
screen.

I have reinstated the screen blanking and setting of the
document and root node to null on newload, will put the changes
back today.  

Also:  Would those of you complaining about "flashing" when switching
documents please try turning "fixed size window" on and confirming that
the problem goes away (as it does on my win98 box) ?  I believe that 
the flash is caused by a Swing invalidate()+pack() which has always 
been in the code, not sure why it's become more visible.  You
might try changing your windows background color to reduce the
severity.

-Bill
--------------
Bill Haneman
+1 353 1 849 0495