Cosmetic Slidey redraw bug

In some of the system tools, if you resize a slidey, while it is "out"
but not pinned, about half the time it does not redraw properly. (I
have not confirmed this on any other machines)

An example is in the SystemBrowser:
 - Collapse the packageSelector slidey.
 - Expand it by hovering the mouse over the "Packages" tab.
 - Drag its right edge to the right.

Most of the time the child view does not repaint. It also happens in
the ViewComposer.

FWIW: Changing LayoutContext>>deferRectangles to answer false seems to
stop the problem from happening.

Steve

Steve,
"Steve Alan Waring" <[hidden email]> wrote in message
news:[hidden email]...
[...]
> An example is in the SystemBrowser:
> - Collapse the packageSelector slidey.
> - Expand it by hovering the mouse over the "Packages" tab.
> - Drag its right edge to the right.
>
> Most of the time the child view does not repaint. It also happens in
> the ViewComposer.
FWIW, I tried this on a desktop and a laptop, but repainting seemed fine on
both systems.  Both are running XP Professional with the most recent
updates.

Don

>
> FWIW: Changing LayoutContext>>deferRectangles to answer false seems to
> stop the problem from happening.
>
> Steve
>

Hi Don,

> FWIW, I tried this on a desktop and a laptop, but repainting seemed fine on
> both systems.  Both are running XP Professional with the most recent
> updates.

Thanks for looking into this.

I see the problem on a similar machine ... WinXP professional + SP2.
The image is a fresh 6.02 image.

I have uploaded a screenshot of what I am seeing to:

http://www.stevewaring.net/images/d6slidey.png

I can also reproduce it on a Win 2003 machine, although I can only use
it via an RDP session where the client is running on the WinXP
professional + SP2 machine.

I tried disabling all hardware acceleration in my video card, but the
problem still occurred. I should be able to get my hands on a couple
more XP machines this weekend.

It might be time to upgrade my video card drivers!

Thanks,
Steve

Steve Alan Waring escribió:
The same configuration here, but the bug doesn't appear.

> I have uploaded a screenshot of what I am seeing to:
> http://www.stevewaring.net/images/d6slidey.png
Odd...

> I tried disabling all hardware acceleration in my video card, but the
> problem still occurred. I should be able to get my hands on a couple
> more XP machines this weekend.
>
> It might be time to upgrade my video card drivers!


Driver brand?
ATI FireGL here, default drivers, default configuration.

Regards,

--
Esteban

Hi Esteban,

> Driver brand?

The card is a GeForce FX 5200. Drivers are v6.14.01.4354 ... same
drivers that came pre-installed when I bought it about 1.5 yrs ago from
Dell. The card is running dual monitors with the desktop extended
across the second monitor.

Thanks!
Steve

Steve,

> The card is a GeForce FX 5200.

I've got one of those in my Dell.

> Drivers are v6.14.01.4354

My driver is 7.8.0.1 released 2/8/2005 and I don't see the redraw problem.

> ... same
> drivers that came pre-installed when I bought it about 1.5 yrs ago from
> Dell. The card is running dual monitors with the desktop extended
> across the second monitor.

I've only got a single monitor though.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Thanks to everyone for the feedback.

I think I might have found out why I am the only one seeing the redraw
problem. If I have "Show window contents while dragging" set to false
... I see the redraw problem. If I set it to true ... no redraw
problem.

Can anyone confirm this?

To change the setting:
 - Open the "Display Properties" (right click Desktop, then
"Properties")
 - Switch to the "Appearance" tab.
 - Click on the "Effects" button.
 - Uncheck "Show window contents while dragging".

Thanks,
Steve

Steve,

> I think I might have found out why I am the only one seeing the redraw
> problem. If I have "Show window contents while dragging" set to false
> ... I see the redraw problem. If I set it to true ... no redraw
> problem.

That's what I see too.  (Win XP Pro sp 1)

    -- chris

Steve,
"Steve Alan Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Thanks to everyone for the feedback.
>
> I think I might have found out why I am the only one seeing the redraw
> problem. If I have "Show window contents while dragging" set to false
> ... I see the redraw problem. If I set it to true ... no redraw
> problem.
>
> Can anyone confirm this?
Changing that setting does it for me, too, although it's not persistent;
it's only when I first strecth out the view.

Don

"Steve Alan Waring" <[hidden email]> wrote in message
news:[hidden email]...
Yes, see the problem now. Amazed it hasn't been seen before now, bearing in
mind it is easy to reproduce if you run with "show window contents while
dragging turned" off.

The interesting thing is that it appears to be because no repaint message is
being sent, although there appears to be an invalid region. Try moving the
mouse over the pin when it happens, and the display will refresh correctly.
Hovering over the pin, so its state changes to hot, only invalidates the
rectangle within which the pin is displayed, so this suggests there is an
invalid rectangle for the damaged area from the resize, but that no paint
message is being dispatched.

Thanks for the bug report.

Blair

Hi Blair,

I have a raw (very raw!) message spy goodie that logs all windows
messages and UserLibrary message sends. It is still close to impossible
to work out what is going on, but I can see the SlidingCardTray getting
a WM_PAINT after you do the invalidates. I can also see its child
getting a WM_PAINT. What I can't see is the child getting a layout.

When SlideyInneyOuteyThing unpins the SlidingCardTray it makes it
unmanaged. As a result when #ensureLayoutValid is sent, it gets passed
up the parent chain, but #validateLayout: not make it back down to the
SlidingCardTray. Adding the method below does stop the problem, but I
don't know if that is the actual fix.

!SlideyInneyOuteyThing methodsFor!

validateSubViewLayouts: aLayoutContext
        super validateSubViewLayouts: aLayoutContext.
        tray isManaged ifFalse: [tray validateLayout: aLayoutContext]! !
!SlideyInneyOuteyThing categoriesFor: #validateSubViewLayouts:!public!
!

Steve

"Steve Alan Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> I have a raw (very raw!) message spy goodie that logs all windows
> messages and UserLibrary message sends. It is still close to impossible
> to work out what is going on, ...

:-). Ah the pleasures of Windows programming...

>....but I can see the SlidingCardTray getting
> a WM_PAINT after you do the invalidates. I can also see its child
> getting a WM_PAINT. What I can't see is the child getting a layout.
>
> When SlideyInneyOuteyThing unpins the SlidingCardTray it makes it
> unmanaged. As a result when #ensureLayoutValid is sent, it gets passed
> up the parent chain, but #validateLayout: not make it back down to the
> SlidingCardTray. ...

Good call Steve. That would also explain why the redraw of the pin causes it
to redraw the tray correctly, since by inserting a little instrumentation I
can see the tray layout getting validated when hovering over the pin.

Not sure yet if your patch is right, but this will definitely be fixed in
the next PL.

Thanks

Blair