Home » Eclipse Projects » GEF » notification and refreshVisuals
| notification and refreshVisuals [message #149645] |
Wed, 01 September 2004 20:20  |
Eclipse User |
|
|
|
Originally posted by: david_michonneau.hotmail.com
Hi,
What is the recommended approach to handle numerous model notifications in
GEF? For instance if I get 10 notifications on a model element, I would like
to avoid the overhead of calling refreshVisuals 10 times.
Looking at the way the repaint optimization is done, I was thinking of doing
something similar for refreshVisuals: have a DeferredRefreshManager mark
EditParts as dirty when their refreshVisuals is called. Then I could extend
the DeferredUpdateManager to call the RefreshManager before painting so that
all EditParts are refreshed, but only once per EditPart. Is that a good
approach or is there a better way to do it?
Thanks,
David
|
|
|
| Re: notification and refreshVisuals [message #149665 is a reply to message #149645] |
Wed, 01 September 2004 20:53  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
You could handle the notifications more intelligently and call
refreshLabel(), refreshIcon(), etc. Have you identified any performance
problems?
You could create a refresh manager. Just be aware that stale
editparts/figures are more dangerous than stale pixels on the screen. You
need to make sure all notifications use this manager, and you may need to
preserve order for some types of notifications, such as removing a child and
adding it to a new parent.
"David Michonneau" <david_michonneau@hotmail.com> wrote in message
news:ch5anr$r9o$1@eclipse.org...
> Hi,
>
> What is the recommended approach to handle numerous model notifications in
> GEF? For instance if I get 10 notifications on a model element, I would
like
> to avoid the overhead of calling refreshVisuals 10 times.
>
> Looking at the way the repaint optimization is done, I was thinking of
doing
> something similar for refreshVisuals: have a DeferredRefreshManager mark
> EditParts as dirty when their refreshVisuals is called. Then I could
extend
> the DeferredUpdateManager to call the RefreshManager before painting so
that
> all EditParts are refreshed, but only once per EditPart. Is that a good
> approach or is there a better way to do it?
>
> Thanks,
>
> David
>
>
|
|
|
| Re: notification and refreshVisuals [message #149672 is a reply to message #149665] |
Wed, 01 September 2004 21:21 |
| Eclipse User |
|
|
|
Originally posted by: david_michonneau.hotmail.com
Actually I haven't identified any performance problem, but we are creating
the notification design now, and it is a concern that we have. Do you
believe there will be no performance issue at all, based on your experience
with GEF?
Handling the notifications more intelligently seems a good solution, but I'm
afraid it will generate a huge amount of code and code paths.
Thanks,
David
"Randy Hudson" <none@us.ibm.com> wrote in message
news:ch5cm1$uae$1@eclipse.org...
> You could handle the notifications more intelligently and call
> refreshLabel(), refreshIcon(), etc. Have you identified any performance
> problems?
>
> You could create a refresh manager. Just be aware that stale
> editparts/figures are more dangerous than stale pixels on the screen. You
> need to make sure all notifications use this manager, and you may need to
> preserve order for some types of notifications, such as removing a child
and
> adding it to a new parent.
>
> "David Michonneau" <david_michonneau@hotmail.com> wrote in message
> news:ch5anr$r9o$1@eclipse.org...
> > Hi,
> >
> > What is the recommended approach to handle numerous model notifications
in
> > GEF? For instance if I get 10 notifications on a model element, I would
> like
> > to avoid the overhead of calling refreshVisuals 10 times.
> >
> > Looking at the way the repaint optimization is done, I was thinking of
> doing
> > something similar for refreshVisuals: have a DeferredRefreshManager mark
> > EditParts as dirty when their refreshVisuals is called. Then I could
> extend
> > the DeferredUpdateManager to call the RefreshManager before painting so
> that
> > all EditParts are refreshed, but only once per EditPart. Is that a good
> > approach or is there a better way to do it?
> >
> > Thanks,
> >
> > David
> >
> >
>
>
|
|
|
| Re: notification and refreshVisuals [message #149680 is a reply to message #149672] |
Wed, 01 September 2004 23:31 |
 Pratik Shah
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
It's usually not an issue. Having the simple optimizations is usually
enough:
1) The set methods in your model should ensure that something is indeed
being changed before firing notification.
2) The listener in your edit part should invoke refreshVisuals() or
refreshChildren() only if it's a property that can affect the look or the
layout, resp.
3) Your figure or refreshVisuals() should call repaint only if a visual
property has changed.
"David Michonneau" <david_michonneau@hotmail.com> wrote in message
news:ch5eb0$1jo$1@eclipse.org...
> Actually I haven't identified any performance problem, but we are creating
> the notification design now, and it is a concern that we have. Do you
> believe there will be no performance issue at all, based on your
experience
> with GEF?
>
> Handling the notifications more intelligently seems a good solution, but
I'm
> afraid it will generate a huge amount of code and code paths.
>
> Thanks,
>
> David
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:ch5cm1$uae$1@eclipse.org...
> > You could handle the notifications more intelligently and call
> > refreshLabel(), refreshIcon(), etc. Have you identified any performance
> > problems?
> >
> > You could create a refresh manager. Just be aware that stale
> > editparts/figures are more dangerous than stale pixels on the screen.
You
> > need to make sure all notifications use this manager, and you may need
to
> > preserve order for some types of notifications, such as removing a child
> and
> > adding it to a new parent.
> >
> > "David Michonneau" <david_michonneau@hotmail.com> wrote in message
> > news:ch5anr$r9o$1@eclipse.org...
> > > Hi,
> > >
> > > What is the recommended approach to handle numerous model
notifications
> in
> > > GEF? For instance if I get 10 notifications on a model element, I
would
> > like
> > > to avoid the overhead of calling refreshVisuals 10 times.
> > >
> > > Looking at the way the repaint optimization is done, I was thinking of
> > doing
> > > something similar for refreshVisuals: have a DeferredRefreshManager
mark
> > > EditParts as dirty when their refreshVisuals is called. Then I could
> > extend
> > > the DeferredUpdateManager to call the RefreshManager before painting
so
> > that
> > > all EditParts are refreshed, but only once per EditPart. Is that a
good
> > > approach or is there a better way to do it?
> > >
> > > Thanks,
> > >
> > > David
> > >
> > >
> >
> >
>
>
|
|
|
| Re: notification and refreshVisuals [message #149723 is a reply to message #149672] |
Thu, 02 September 2004 17:30 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The only performance concern I I have seen is to avoid calling
refreshChildren() all the time, especially in tree Editparts. Instead, call
addChild(...) and removeChild(...) as appropriate. This is the difference
of O(n) and O(1) times the number of children changing.
"David Michonneau" <david_michonneau@hotmail.com> wrote in message
news:ch5eb0$1jo$1@eclipse.org...
> Actually I haven't identified any performance problem, but we are creating
> the notification design now, and it is a concern that we have. Do you
> believe there will be no performance issue at all, based on your
experience
> with GEF?
>
> Handling the notifications more intelligently seems a good solution, but
I'm
> afraid it will generate a huge amount of code and code paths.
>
> Thanks,
>
> David
|
|
|
Goto Forum:
Current Time: Thu Apr 25 17:35:16 GMT 2024
Powered by FUDForum. Page generated in 0.02725 seconds |
] 
Search
Help
Register
Login
Home
