Eclipse Community Forums: GEF » paint optimization

Home » Eclipse Projects » GEF » paint optimization

Tue, 31 August 2004 10:56

Eclipse User

Originally posted by: david_michonneau.hotmail.com

Hi,

I believe the DeferredUpdateManager is queuing all the repaint event to have
only repaint called once per modified figure no matter how many times
refreshVisuals has been called. Can you confirm if this is correct, and does
it mean I don't have to worry about firing too many events in my model that
could make the ui blink?

Thanks,

David

Re: paint optimization [message #149226 is a reply to message #149211]

Tue, 31 August 2004 11:20

Eclipse User

Yes, more or less. But that doesn't mean that you shouldn't write good code
:-)
DeferredUpdateManager marks figures as dirty and repaints them once per
performUpdate() invocation. If anybody's forcing updates anywhere, there
could be multiple paint calls.

"David Michonneau" <david_michonneau@hotmail.com> wrote in message
news:ch23c1$ksi$1@eclipse.org...
> Hi,
>
> I believe the DeferredUpdateManager is queuing all the repaint event to
have
> only repaint called once per modified figure no matter how many times
> refreshVisuals has been called. Can you confirm if this is correct, and
does
> it mean I don't have to worry about firing too many events in my model
that
> could make the ui blink?
>
> Thanks,
>
> David
>
>

Re: paint optimization [message #149539 is a reply to message #149211]

Wed, 01 September 2004 04:17

Eclipse User

Originally posted by: g.wagenknecht.planet-wagenknecht.de

David Michonneau wrote:
> I believe the DeferredUpdateManager is queuing all the repaint event
> to have only repaint called once per modified figure no matter how
> many times refreshVisuals has been called. Can you confirm if this is
> correct, and does it mean I don't have to worry about firing too many
> events in my model that could make the ui blink?

You can also create our own update manager (inherited from
DeferredUpdateManager) that queues updates during processing a hugh tree of
events...

Cu, Gunnar

Re: paint optimization [message #149583 is a reply to message #149539]

Wed, 01 September 2004 10:45

Eclipse User

Originally posted by: none.us.ibm.com

The default one is already very optimized. It keeps a map of
figures->damage regions, and only when the paint is actually going to occur
does it calculate the clipping of damage (by walking the parent tree and
intersecting rectangles), and then unions the damaged regions to create the
rectangle which needs to be repainted.

"Gunnar Wagenknecht" <g.wagenknecht@planet-wagenknecht.de> wrote in message
news:ch4070$hqq$1@eclipse.org...
> David Michonneau wrote:
> > I believe the DeferredUpdateManager is queuing all the repaint event
> > to have only repaint called once per modified figure no matter how
> > many times refreshVisuals has been called. Can you confirm if this is
> > correct, and does it mean I don't have to worry about firing too many
> > events in my model that could make the ui blink?
>
> You can also create our own update manager (inherited from
> DeferredUpdateManager) that queues updates during processing a hugh tree
of
> events...
>
> Cu, Gunnar
>
>

Re: paint optimization [message #149703 is a reply to message #149539]

Thu, 02 September 2004 08:18

Eclipse User

Originally posted by: david_michonneau.hotmail.com

I am interested in that approach, but if I inherit DeferredUpdateManager,
how can I hook it up to the LightweightSystem?

Thanks,

David

"Gunnar Wagenknecht" <g.wagenknecht@planet-wagenknecht.de> wrote in message
news:ch4070$hqq$1@eclipse.org...
> David Michonneau wrote:
> > I believe the DeferredUpdateManager is queuing all the repaint event
> > to have only repaint called once per modified figure no matter how
> > many times refreshVisuals has been called. Can you confirm if this is
> > correct, and does it mean I don't have to worry about firing too many
> > events in my model that could make the ui blink?
>
> You can also create our own update manager (inherited from
> DeferredUpdateManager) that queues updates during processing a hugh tree
of
> events...
>
> Cu, Gunnar
>
>

Re: paint optimization [message #149731 is a reply to message #149539]

Thu, 02 September 2004 13:33

Eclipse User

Originally posted by: none.us.ibm.com

> David Michonneau wrote:
> > I believe the DeferredUpdateManager is queuing all the repaint event
> > to have only repaint called once per modified figure no matter how

That's incorrect. Painting only occurs once period, not once per-figure.
More specifically, it occurs as soon as the asyncExec is dispatched in
response to the first call to repaint(). So if everything is happening
synchronously in response to a UI event, there is just one repaint.

> > many times refreshVisuals has been called. Can you confirm if this is
> > correct, and does it mean I don't have to worry about firing too many
> > events in my model that could make the ui blink?
>
> You can also create our own update manager (inherited from
> DeferredUpdateManager) that queues updates during processing a hugh tree
of
> events...
>
> Cu, Gunnar
>
>

Previous Topic:	notification and refreshVisuals
Next Topic:	palette question

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jun 10 16:23:33 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter