Problems with invalidate now and damage regions

I am looking at a problem with a hierarchy view we created
and how its use interacts with the scroll bars. The symptom
I see is we direct the view to select an item that is out of
view and the item reappears in two places. This happens
because of the way the scroll wrapper and its scrollbars are
updated along with the view selection.

Some of the scrollbar updates use;
invalidateRectangle: aRect repairNow: true.
The problem being that when the damage areas are merged it
includes the whole viewable region and the hierarchy view
is not yet ready to be updated, i.e. the model has not yet
been completely updated.

It would seem that either all graphics updates should be
deferred until the current event has completed processing,
or the damage rectangles should not be merged into larger
rectangles.

Comments anyone?

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I offered a fix for that about six years ago. It was a nice performance improvement. One of many things that got lost in the hope that Pollock would solve all problems.

Paul Baumann


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond
Sent: Monday, August 29, 2011 16:38
To: VWNC
Subject: [vwnc] Problems with invalidate now and damage regions

...
It would seem that either all graphics updates should be
deferred until the current event has completed processing,
or the damage rectangles should not be merged into larger
rectangles.

Comments anyone?
...

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Terry: which VW version, and what message(s) do you use to select the
item? I recall the reverse problem, i.e. the element not being displayed
until a forced refresh, but since I don't see your problem then our
patch for that maybe solved both problems.

If anyone's interested, we also have extensions that enable a tree view
to maintain its selection and the openness of its branches during a
model update, and to cope with tree views whose models are not trees,
but are usefully shown as trees - e.g. DAGs or graphs with cycles.

Steve



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ah, I thought you'd just created a hierarchy view instance, I didn't
realise you meant a class. Yes, the VW mechanisms for display updates in
response to model updates are flawed in a number of ways in both design
and implementation. Such a shame that Cincom invested so much effort in
a non-backwards compatible Pollock, rather than keeping the public
interface of ApplicationModels and #windowSpecs, and rebuilding the
widget support. And that the WindowManager event handling has so many
holes in it that any attempt to hold back on display refreshes is doomed
- one "Dialog confirm:" in the middle of your long UI operation, and all
the windows try to update straightaway.

It's still amazing what can be built on top of VW, and how much freedom
we have to change, extend and correct VW itself. Just a shame how hard
it is for those corrections and improvements to end up in the base. At
the end of the day it's the priorities set by product management that
determine these things. The message from vwnc and vw-dev doesn't seem to
be getting through, or then it gets drowned out by messages we don't
see, whether from Cincom outside VW, from VW developers in Cincom, or
(my guess) from big VW customers who talk directly to Cincom.

Steve
the
> > item? I recall the reverse problem, i.e. the element not being
> displayed
> > until a forced refresh, but since I don't see your problem then our
> > patch for that maybe solved both problems.
> >
> > If anyone's interested, we also have extensions that enable a tree
> view
> > to maintain its selection and the openness of its branches during a
> > model update, and to cope with tree views whose models are not
trees,
> > but are usefully shown as trees - e.g. DAGs or graphs with cycles.
> >
> > Steve
> >
> >
> >
> > > -----Original Message-----
> > > From: [hidden email] [mailto:[hidden email]]
On

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc