[VW7.4] Window damage repair - limited queue size?

It seems to me that the queue which is collecting window damages (GUI)
is of limited size(?).

When moving a window above another for only a short period of time (few
mouse points only), invalidation and repainting works correct. When
moving the winow a lot more, however, invalidation gets garbled, i.e.
parts of the previously covered window don't get repainted and they are
left blank.

This is true only for VW's own ScheduledWindows. Covering a VW window
with, say, a Firefox app or something else has no effect, because
redrawing takes place immediately.

Does any VW patch exist to fix this?

Cheers,
Andre

Yep, I and our customers are getting pretty bored of this. My request to
Cincom (hi Eliot!) would be: if you can't solve it properly in a short
time, either by passing events to the VI as they are received or by
growing the VM's event buffer as needed, please just triple the current
circular event buffer's size or something.

Steve

From: [hidden email] [mailto:[hidden email]]

If you run an assert engine you will see asserts saying that some queue
overflowed.




Andre Schnoor wrote:


--
Reinout Heeck
-------------
Idle curiosity is the enemy of a quiet life.

Andre,

> It seems to me that the queue which is collecting window damages  
> (GUI) is of limited size(?).

Yes, this is true. It is limited to 1024 OS messages (not just damage  
messages), although we try to collapse as many as we can, it still  
can overflow.

> This is true only for VW's own ScheduledWindows. Covering a VW  
> window with, say, a Firefox app or something else has no effect,  
> because redrawing takes place immediately.
>
> Does any VW patch exist to fix this?

No, because it is an VM engine issue.

The problem is manyfold. But basically the engine blocks on event  
callbacks, and while this happens, all OS events are queued in the  
engine.

Engine work is required to 'fix' this, and it will be done, however,  
higher priority engine projects are being worked on first, obviously.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Going with Steven Kelly's original suggestion, is there anything
fundamentally wrong about increasing the queue limit until a better fix is
in place? Or even make that a VM setting that we could control?

ObjectMemory registerObject: 8192 withEngineFor: 'eventQueueSize'.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Samuel S. Shuster [mailto:[hidden email]]
Sent: Tuesday, March 21, 2006 10:20 AM
To: Andre Schnoor
Cc: vwnc-list
Subject: Re: [VW7.4] Window damage repair - limited queue size?

Andre,

> It seems to me that the queue which is collecting window damages  
> (GUI) is of limited size(?).

Yes, this is true. It is limited to 1024 OS messages (not just damage  
messages), although we try to collapse as many as we can, it still  
can overflow.

> This is true only for VW's own ScheduledWindows. Covering a VW  
> window with, say, a Firefox app or something else has no effect,  
> because redrawing takes place immediately.
>
> Does any VW patch exist to fix this?

No, because it is an VM engine issue.

The problem is manyfold. But basically the engine blocks on event  
callbacks, and while this happens, all OS events are queued in the  
engine.

Engine work is required to 'fix' this, and it will be done, however,  
higher priority engine projects are being worked on first, obviously.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

From: Samuel S. Shuster [mailto:[hidden email]]
> > It seems to me that the queue which is collecting window damages
> > (GUI) is of limited size(?).
>
> Yes, this is true. It is limited to 1024 OS messages...
> Engine work is required to 'fix' this, and it will be done, however,  
> higher priority engine projects are being worked on first, obviously.

Please could you increase the limit in the meantime: probably a
one-liner, exInQueue.c line 46:

#define shiftCount 10
=>
#define shiftCount 12

i.e. 2^12 = 4096 slots. Do I guess right that each queue element is 20
bytes, so this would change the queue from 20KB to 80KB - hardly a
noticeable increase, but will make VW noticeably better behaved.

Cheers,
Steve

Steven,

Can you try to recompile VM with this change and give it a try ?  or
send it to few people to test the new VM  against their application -
I'd be one of them.

--Mark

Steven Kelly wrote:

Boris Popov wrote:
> Going with Steven Kelly's original suggestion, is there anything
> fundamentally wrong about increasing the queue limit until a better fix is
> in place? Or even make that a VM setting that we could control?
>
> ObjectMemory registerObject: 8192 withEngineFor: 'eventQueueSize'.
>
> Cheers!
>
> -Boris
I'd highly appreciate that, because - at least for a commercial desktop
application in the media business (which is what I'm currently trying to
sell to the people) - this kind of "unimportant" unglyness is usually
what makes them believe the overall quality of the product is sloppy and
probably not worth the money.

I thought the window dragging was handled by the OS in a separate
thread, hmm.

Or another suggestion: I could simply redraw the whole window, in case
the event queue went above a certain size. Is that information available
somewhere? The OE could perhaps insert an "invalidate all" event in that
case, which would also help (if the queue information is available, I
could do that myself, of course).

What I am doing now during presentations is to quickly double-click on
the window caption twice, wait for the refresh and nervously look around
if somebody in the audience noticed it ...

Regards,
Andre

BTW: I'm not currently able to compile the VM, so a "soft" solution of
the problem is required.

Mark,

Sadly, the line between being a helpful customer and doing Cincom's work
for them has to be drawn somewhere. For me, as someone who doesn't even
have a C compiler installed, recompiling the VM is the wrong side of the
line.

I'd love to see the change be included in a dev build the next time
Eliot has to recompile the VM anyway. Even if Eliot and Sames hate me
for saying it :-).

Steve

Hi,

I was very unhappy with the damage repair for years and I thought, this problem should obviously solved by cincom without opening a case!
For customers we are showing our products the first thing they see is a somtimes destroyed window. This looks VERY unprofessional and I cannot understand, why this problem is a not so high priority one.
If it can be patched so easily, where are the patches?

Cincom, please compile a version of the VM with a larger event queue. I understand, that this is not a complete resolution of the problem, but at a first step, the smalltalk gui applications will look more professional.

Klaus


Collogia AG
Ubierring 11
 
50678 Köln
Germany
+49 221 336080
http://www.collogia.de

-----Ursprüngliche Nachricht-----
Von: Samuel S. Shuster [mailto:[hidden email]]
Gesendet: Dienstag, 21. März 2006 19:20
An: Andre Schnoor
Cc: vwnc-list
Betreff: Re: [VW7.4] Window damage repair - limited queue size?

Andre,

> It seems to me that the queue which is collecting window damages  
> (GUI) is of limited size(?).

Yes, this is true. It is limited to 1024 OS messages (not just damage  
messages), although we try to collapse as many as we can, it still  
can overflow.

> This is true only for VW's own ScheduledWindows. Covering a VW  
> window with, say, a Firefox app or something else has no effect,  
> because redrawing takes place immediately.
>
> Does any VW patch exist to fix this?

No, because it is an VM engine issue.

The problem is manyfold. But basically the engine blocks on event  
callbacks, and while this happens, all OS events are queued in the  
engine.

Engine work is required to 'fix' this, and it will be done, however,  
higher priority engine projects are being worked on first, obviously.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?





Diese Nachricht ist vertraulich. Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte den Absender. Das unbefugte Kopieren oder Weiterleiten ist nicht gestattet. Wegen der Manipulierbarkeit von E-Mails übernehmen wir keine Haftung für den Inhalt.

Here's a quick & dirty fix for the problem (it cost me half a day):

The hack provided by the attached package hooks into the #eventMoved:
and #eventResize: messages of ScheduledWindow, where it calls a class
method that forces a full refresh of all currently open ScheduledWindows
that had any (partial) damage since the last refresh. The
DoubleBufferingWindowDisplayPolicy is used to reduce flicker to a
minimum. However, because the (partial) invalidation events can not be
deleted from the queue (they are queued before #eventMoved:), the full
repaint will follow them and thus cause a small visual glitch. Anyway,
this is better than always doing the refresh manually.

This is considered a temporary solution only and is still a work in
progress. Maybe it could serve as a starting point for further
improvements. Ideas:

Currently the VM doesn't notify the image about a queue overflow (e.g.
by queuing a special "overflow" event). This is a valuable information.
Another "blocking now" event would be helpful, informing the image that
future events will be postponed during a blocking OE operation (e.g.
window movement). Provided these small additions were available, a
nearly perfect workaround is possible:

1. Reset all open window's sensors to "not damaged" (see the package),
once a "blocking now" event is received. This prevents regular damages
from being unnecessarily accumulated.

2. Wait for the "overflow event" to occur and refresh all windows that
had new damages

3. or simply do nothing, if no overflow occured.

Any improvements welcome.

HTH

Andre Schnoor

<?xml version="1.0"?>

<st-source>
<time-stamp>From VisualWorks®, 7.4 of 5. Dezember 2005 on 22. März 2006 at 21:59:09</time-stamp>
<!-- Package Window Damage Fix(1.1,andre)= -->


<component-property>
<name>Window Damage Fix</name> <type>package</type>
<property>comment</property> <value>'This package provides a quick and dirty workaround for the well-known window damage problem: When moving a VW window around on the screen, the VM''s event queue eventually overflows, which results in only partially repainted window content.

The hack provided by this package hooks into the #eventMoved: and #eventResize: messages of ScheduledWindow, where it calls a class method that forces a full refresh of all currently open ScheduledWindows that had any (partial) damage since the last refresh. The DoubleBufferingWindowDisplayPolicy is used to reduce flicker to a minimum. However, because the (partial) invalidation events can not be deleted from the queue (they are queued before #eventMoved:), the full repaint will follow them and thus cause a small visual glitch.

This is considered a temporary solution only and is still a work in progress. Maybe it could serve as a starting point for further improvements.

Currently the VM doesn''t notify the image about a queue overflow (e.g. by queuing a special "overflow" event). This could be a valuable information. A special notification event would be helpful, informing the image that future events will be postponed for a blocking OE operation (e.g. window movement). Provided these small additions were available, a nearly perfect workaround would be possible:

Reset all open window''s sensors to "not damaged", once a "blocking now" event is received. Wait for the "overflow event" to occur and refresh all windows that had new damages, or simply do nothing, if no overflow occurs.


Andre Schnoor
'</value>
</component-property>

<class>
<name>EventSensor</name>
<environment>UI</environment>
<super>UI.ApplicationWindowSensor</super>
<private>false</private>
<indexed-type>none</indexed-type>
<inst-vars>collapseEvents queueLocked hadDamage </inst-vars>
<class-inst-vars></class-inst-vars>
<imports></imports>
<category>Interface-Events-Support</category>
<attributes>
<package>Window Damage Fix</package>
</attributes>
</class>

<comment>
<class-id>UI.EventSensor</class-id>
<body>The sensor for event-driven windows. EventSensor queues mouse, keyboard and window events into metaInput (an instance of EventQueue), so that the window's controller does not have to wait on multiple queues. In addition, EventSensor collapse MouseMovedEvents by default.

Instance Variables:
        collapseEvents &lt;Boolean&gt; Whether or not to collapse MouseMovedEvents.
        queueLocked &lt;Boolean&gt; Whether or not to lock the event queue. This is used to prevent #checkForEvents to empty the event queue (metaInput), during the time that an event is being process.
</body>
</comment>



<methods>
<class-id>UI.EventSensor</class-id> <category>private</category>

<body package="Window Damage Fix" selector="privateAddDamage:">privateAddDamage: aRectangle
        "Remember that I had some damage during window movement"
        hadDamage := true.
        ^super privateAddDamage: aRectangle.</body>
</methods>

<methods>
<class-id>UI.EventSensor</class-id> <category>testing</category>

<body package="Window Damage Fix" selector="hadDamage">hadDamage
        ^hadDamage == true</body>

<body package="Window Damage Fix" selector="hadDamage:">hadDamage: aBoolean
        hadDamage := aBoolean.</body>
</methods>


<methods>
<class-id>UI.ScheduledWindow class</class-id> <category>window management</category>

<body package="Window Damage Fix" selector="refreshWindowsExcept:">refreshWindowsExcept: thisWindow

        self scheduledWindows do:[ :w |
                | sensor |
                (sensor := w sensor) notNil ifTrue:[
                        (w ~~ thisWindow and:[ sensor hadDamage ]) ifTrue:[
                                DoubleBufferingWindowDisplayPolicy new
                                        displayDamageList: (Array with: w bounds)
                                        in: w ].
                        sensor hadDamage: false.
                ].
        ].</body>
</methods>


<methods>
<class-id>UI.ScheduledWindow</class-id> <category>event driven events</category>

<body package="Window Damage Fix" selector="resizeEvent:">resizeEvent: aResizeEvent
        | type |

        "### added this:"
        self class refreshWindowsExcept: self.

        self triggerEvent: #resize.
        type := aResizeEvent key.
        self extentEvent: aResizeEvent rectangle extent.
        self updateEvent: type.
        self reportWindowEvent: type with: aResizeEvent.
        ^nil</body>

<body package="Window Damage Fix" selector="moveEvent:">moveEvent: aMoveEvent
        "The window has been moved, notify subcomponents of location change and report this event."
        | type |

        "### added this:"
        self class refreshWindowsExcept: nil.

        self triggerEvent: #move.
        type := aMoveEvent key.
        self updateEvent: type.
        self reportWindowEvent: type with: aMoveEvent newOrigin.
        ^nil</body>
</methods>



</st-source>

Andre Schnoor wrote: Does this only happen when moving or resizing a window?

From: Ralf Propach [mailto:[hidden email]]
> Andre Schnoor wrote:
> > It seems to me that the queue which is collecting window damages
(GUI)
> > is of limited size(?).
> >
> > When moving a window above another for only a short period of time
(few
> > mouse points only), invalidation and repainting works correct. When
> > moving the winow a lot more, however, invalidation gets garbled,
i.e.
> > parts of the previously covered window don't get repainted and they
are
> > left blank.
> >
> > This is true only for VW's own ScheduledWindows. Covering a VW
window
> > with, say, a Firefox app or something else has no effect, because
> > redrawing takes place immediately.
> >
> Does this only happen when moving or resizing a window?

Yes, that's the problem we're talking about. It's solved though - or at
least I made the necessary changes in exInQueue.c and sent them to
Sames, along with a compiled VM that showed the correction worked. We
agreed that James Robertson would shepherd the changes through to a new
official VM version, and he would then announce it to vwnc.

Steve

Ralf Propach wrote:
AKAIK, yes. Perhaps there are other circumstances that block event
processing from the image, but I don't know of them.

Actually the whole image seems to be blocked then, because my app
completely stops all its running tasks while I am dragging a window.
That's bad, because it's a real-time media application that runs all the
time.

Andre