Invisible outer Grid triggers screen repaint problem in IE7. Any workarounds?

[John Gunther]

I've run into a perplexing screen repaint problem in IE7.

Symptoms are that when I move a widget to a new position on an
AbsolutePanel, the old widget does not get erased from the display
("ghosting") and the new widget doesn't get drawn in the new location,
unless I switch to another browser tab and back again (or switch to
another application and back again) which presumably forces an IE7
screen repaint.

It's as if IE7 thinks it doesn't need to repaint (but it's wrong).

The widgets are 1x1 Grids, that have visibility: hidden which contain
another 1x1 Grid with visibility: visible which contains a Button (all
this is to allow more flexible alignment of the enclosed Button
without the outer grid grabbing mouseovers and such):

DOM.setStyleAttribute(getElement(), "visibility","hidden");
DOM.setStyleAttribute(innerGrid.getElement(), "visibility",
"visible");


If I set both inner/outer Grids to have visibility: visible, then the
screen repaints without my having to flip to another tab (but the
mouseover grabbing problem isn't fixed in that case).

Everything works just fine in Firefox 2. The same code used to work
just fine in IE7, too, but I made some changes to the top-level
widgets that contain all this (removing a top-level DockPanel that had
held everything else, etc.) and the strange stuff apparently happened
sometime after, and may be related in some unknown way to, those
changes.

Anyone ever seen anything along these lines? Any workarounds?

John

[John Gunther]

By looking at a previous version that worked and comparing it to the
one that didn't, I found this (even more perplexing) workaround:

DOM.setStyleAttribute(topLevelAbsolutePanel.getElement(),
"fontFamily", "");

Since "" was the "use the default" font family I was using anyway,
this is a do-nothing line. In IE7, however, it apparently somehow
forces a repaint, I guess. The (presumed IE7, and by browser-bug-
inheritance, GWT bug) was triggered when I reorganized the code so
that the above line didn't get executed if it didn't need to be (so,
now, I guess I have to un-reorganize, or, "defacto" it).

I don't fully trust this workaround since the problem might reappear
if IE7 changes in a way that makes it "smarter" and doesn't force a
repaint with such a do-nothing font-family change. For example, other
top level setStyleAttribute do-nothing changes I tried (border,
background-color, etc.) didn't fix the problem.

If anyone knows what's going on here or has a more reliable and
intelligible way to get IE7 to repaint in such situations, please
reply.

John

[Ian Bambury]

So basically, you have a button in a visible grid in a hidden grid in an absolutepanel, yep?

 

And when you move it, it doesn't get repainted in IE7

 

Is that right?

 

Ian

2008/8/19 John Gunther <johncurt...@yahoo.com>

Stuff the environment - Print this email
_______________________________________

[John Gunther]

Yes, that is it.

On Aug 18, 11:41 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> So basically, you have a button in a visible grid in a hidden grid in an
> absolutepanel, yep?
>
> And when you move it, it doesn't get repainted in IE7
>
> Is that right?
>
> Ian
>

> 2008/8/19 John Gunther <johncurtisgunt...@yahoo.com>

> --
> Ianhttp://examples.roughian.com
> _______________________________________

[Ian Bambury]

Mmm...

 

Bit of a kludge, but

 

DOM.setStyleAttribute(absolutepanel.getElement(), "visibility", "visible");

 

after the move seems to work

 

Ian

[John Gunther]

Sounds great to me. More reliable and less kludgey than the black
magic of setting the font-style I was going to go with. Sorry for the
slow reply was distracted by an unrelated bug.

BTW, thanks for the great DockPanel tutorial/demo; makes it trivial to
figure out how DockPanel will place your widgets:

http://examples.roughian.com/index.htm#Panels~DockPanel

John

[John Gunther]

I applied your technique successfully. There was a parent container of
these "aligned buttons" that IE7 was not repainting correctly and by
using the do-nothing lines (after all repositioning of images was
done):

DOM.setStyleAttribute(parentContainer.getElement(),
"visibility","hidden");
DOM.setStyleAttribute(parentContainer.getElement(),
"visibility","visible");

Then IE7 repainted everything properly. These lines didn't slow
performance significantly. Thanks again.

John

[Ian Bambury]

Did you try it without setting it to hidden, just 'revisiblising' it? (It's nearly tomorrow here and I can't be bothered to find the right word :-)

 

In my (admittedly rather minimalistic) test, it worked with just the second DOM line.

 

Ian

 

Might cut clock cycle or two off it - I don't suppose you ever had to worry about how many ticks an assembler command took on a Z80 or 6502 :-)

2008/8/22 John Gunther <johncurt...@yahoo.com>

[Paul Sullivan]

Sorry - completely off topic
 
6502... oh those were the days!!
 
I was a mere boy when the good ol' 64 taught me the basics of ML :)
 
Be good to hark on about those days Ian if your interested :) mail me luap...@hotmail.com
 
Do much win32 MASM nowadays?
 
Paul

---

Date: Fri, 22 Aug 2008 23:44:30 +0100
From: ianba...@gmail.com
To: Google-We...@googlegroups.com
Subject: Re: Invisible outer Grid triggers screen repaint problem in IE7. Any workarounds?

[Ian Bambury]

Well, apart from writing a bat and wall game on a Spectrum (probably the first proper program I ever wrote) and converting IBM360 Assembler programs to Cobol, I've not really been that involved. It's always been in the same category as swimming the Atlantic: it would be nice to be able to say I'd done it, but I don't actually want to do it :-)

 

But I did get my feet wet once or twice.

 

Ian

2008/8/23 Paul Sullivan <luap...@hotmail.com>

[John Gunther]

Ian,

Sorry for the delayed response, missed your re-post. My recollection
is I tried "visibility: visible" without the "visibility: hidden"
first, and it seemed that IE7 was smart enough to realize I hadn't
changed a thing, and to ignore me.

Just in case you are curious to reproduce this on your own with the
actual code, it's the grouped bar chart on the Client-side GChart 2.2
demo application (accessible from the home page) where I first saw the
symptoms. If you comment out the two lines that do the invisible/
visible thing from GChart.java (or, even one of them, if my memory
holds) then, in IE7, the "ghosts" of the buttons' previous positions
on top of each bar remain behind, after clicking the update button.

John C. Gunther
http://gchart.googlecode.com

On Aug 23, 8:29 am, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> Well, apart from writing a bat and wall game on a Spectrum (probably the
> first proper program I ever wrote) and converting IBM360 Assembler programs
> to Cobol, I've not really been that involved. It's always been in the same
> category as swimming the Atlantic: it would be nice to be able to say I'd
> done it, but I don't actually want to do it :-)
>
> But I did get my feet wet once or twice.
>
> Ian
>

> 2008/8/23 Paul Sullivan <luapp...@hotmail.com>

>
> > Sorry - completely off topic
>
> > 6502... oh those were the days!!
>
> > I was a mere boy when the good ol' 64 taught me the basics of ML :)
>
> > Be good to hark on about those days Ian if your interested :) mail me

> > luapp...@hotmail.com