[ENH] Cursor change cache

Hello VWNC,

  I have had a chance to notice that, sometimes, frequent cursor
  changes can become a performance bottleneck.  Hence, I prototyped a
  cursor change cache in class Cursor.  Essentially, it will update
  the current cursor with a maximum frequency of 20hz.  In addition,
  the approach supports immediate cursor updates for GC.  It should
  self initialize on its own.

  Hopefully it helps.  Feel free to modify this to suit your needs.
  The attached file is the complete fileout of the modified Cursor
  class.  The changes were made on top of VW 7.2.1nc.

--
Best regards,
 Andres                          mailto:[hidden email]

Andres Valloud wrote:
>   I have had a chance to notice that, sometimes, frequent cursor
>   changes can become a performance bottleneck.  Hence, I prototyped a
>   cursor change cache in class Cursor.  Essentially, it will update
>   the current cursor with a maximum frequency of 20hz.  In addition,
>   the approach supports immediate cursor updates for GC.  It should
>   self initialize on its own.

It seems you weren't aware of the ThrottledCursor package. I wrote that
several years ago when publishing to Store would drive my X server to
take 80% CPU due to cursor changing.

ThrottledCursor should be listed on the 'cool things in the open
repository' page of the Cincom wiki, however the wiki is not responding
right now so I cannot provide the link.

I thought this package would no longer be needed until someone reported
that it gave major gains when using remote desktop software.


I like your idea of the GC cursor being given priority although in
reality I never missed that feature in ThrottledCursor.



R
-

Hello Reinout,

Wednesday, June 7, 2006, 3:03:26 AM, you wrote:

RH> It seems you weren't aware of the ThrottledCursor package. I wrote
RH> that several years ago when publishing to Store would drive my X
RH> server to take 80% CPU due to cursor changing.

One has to wonder if it wouldn't be a good time to get this feature
built into VisualWorks? :)

RH> I thought this package would no longer be needed until someone
RH> reported that it gave major gains when using remote desktop
RH> software.

Ah yes, if you see cursor flicker in Exceed, it's not cool at all ---
get that mouse off those windows!

RH> I like your idea of the GC cursor being given priority

Thanks! :)

Oh by the way, the implementation I sent has a bug, it also needs to
make sure the cursor is installed.  Otherwise you will get a primitive
failure on startup when you change platforms.

--
Best regards,
 Andres                            mailto:[hidden email]

We use the package in the images we access via RemoteDesktop. The
speedup can be quite dramatic, in on case it was several hundred
percent. However the package can get confused about which cursor to show
with the result that the suddenly the hourglass might become the cursor
shown when the system is not busy!

Joerg

-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
[hidden email]
 

CONFIDENTIALITY NOTICE
Unless otherwise indicated this email contains information that is
private
and confidential. If you have received it in error, please notify the
sender
and delete this message along with any attachments.

Joerg Beekmann wrote:

> However the package can get confused about which cursor to show
> with the result that the suddenly the hourglass might become the  
> cursor
> shown when the system is not busy!


It is hard to tell whether that is a fault of the package because the  
VW cursor swapping algorithm itself is not thread-safe. Particularly  
having multiple threads running long operations wrapped in a  
#showWhile: will break if any of those threads can block and  
relinquish control to the other long running operation. It may well  
be that ThrottledCursor exacerbates the effect when it occurs, I  
don't know.

Please be aware that I haven't used the package for quite a while  
now, so I am not maintaining it. IOW if you do find a bug and have a  
fix go right ahead and publish it....


Fixing the base image so that cursors are thread-safe is a non-
trivial task: naively one could think that  cursor state should be  
attached to the WindowManager so that hovering over different windows  
would show the correct cursor for each windo. However some cursor  
switching happens in threads that are forked off from that WM  
process, unfortunately the VW threading model makes it very hard to  
find the correct WM to register the cursor change with... I dare say  
this is one of the things Pollock won't fix ;-)


Cheers,

Reinout
-------

In my experience cursor confusion is much more common with the package
than without it. I was not trying to assign blame but merely pointing
out, as you do in a much clearer fashion, that there is a good reason
for not integrating this packet into the base.

I am beginning to form an opinion that the way VW changes
the cursor needs to be reevaluated. For example, why should
an end user see the cursor change as a result of a background
process accessing the disk? Or why should the end user see
the GC cursor?

Additionally, it seems to me that the active cursor should
be a function of what window the cursor is in and globally
changing the cursor is not a good idea. So, I really don't
think the cursor should be changed by a background process.

Terry
 
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

On Jun 8, 2006, at 1:48 PM, Terry Raymond wrote:

> I am beginning to form an opinion that the way VW changes
> the cursor needs to be reevaluated. For example, why should
> an end user see the cursor change as a result of a background
> process accessing the disk?

Yes, fully agreed.

> Or why should the end user see
> the GC cursor?

That is defendable, since the user cannot interact during a GC.


> Additionally, it seems to me that the active cursor should
> be a function of what window the cursor is in and globally
> changing the cursor is not a good idea.

Indeed, this is a concern since the introduction of MultiProcUI.


> So, I really don't
> think the cursor should be changed by a background process.

This is too simplistic a statement. Generally forked (non-UI)  
processes are capable of blocking user interaction through several  
mechanisms, for example by hogging the CPU at or above UI priority,  
by doing non-threaded C-callouts or by more explicit interaction like  
where the UI waits for a semaphore to be signaled by a forked process.

In that light it seems appropriate to me that #showWhile: is called  
by non-UI processes to hint the system of blockage. How to make the  
base system percolate such a hint to the correct WindowManager in a  
general way is beyond me though...

Any ideas? Am I wishing for too much magic now?

R
-

Reinout Heeck wrote:
... though some of our users think that the garbage cursor is a tongue
sticking out at them ;)

Actually, the problem existed before the MPUI, it is just that
the MPUI amplified the effects.

> > So, I really don't
> > think the cursor should be changed by a background process.
>
> This is too simplistic a statement. Generally forked (non-UI)
> processes are capable of blocking user interaction through several
> mechanisms, for example by hogging the CPU at or above UI priority,
> by doing non-threaded C-callouts or by more explicit interaction like
> where the UI waits for a semaphore to be signaled by a forked process.

I prefer to use a different model. I see the smalltalk image as a kind
of OS. When we use that for a model we generally don't see an OS
service changing the cursor when it hogs the CPU. Furthermore, we
don't see Excel changing the cursor when the Visio window is active.

There are background processes that do work under the direction of
a user window application. I would rather these processes communicate
their processing state to their controlling window. Then it would
become the responsibility of the window to display the appropriate
cursor when the window is active.

> In that light it seems appropriate to me that #showWhile: is called
> by non-UI processes to hint the system of blockage. How to make the
> base system percolate such a hint to the correct WindowManager in a
> general way is beyond me though...
>
> Any ideas? Am I wishing for too much magic now?

With smalltalk processes there is no distinction between a processes
spawned as a lightweight thread for an application and a process that
kind of operates as a service. It is up to the developer to use the
proper model and make sure his processes operate accordingly.

Additionally, I think the window or its sensor should keep
a reference to what it thinks should be the window's cursor.
Once you have this, it would be quite simple to display the
cursor when the window is activated and also permit it to
be updated by a background process.

> R
> -

Terry
 
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================