Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » paint optimization
paint optimization [message #149211] Tue, 31 August 2004 14:56 Go to next message
Eclipse UserFriend
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 15:20 Go to previous messageGo to next message
Pratik Shah is currently offline Pratik ShahFriend
Messages: 1077
Registered: July 2009
Senior Member
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 08:17 Go to previous messageGo to next message
Eclipse UserFriend
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 14:45 Go to previous messageGo to next message
Eclipse UserFriend
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 12:18 Go to previous messageGo to next message
Eclipse UserFriend
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 17:33 Go to previous message
Eclipse UserFriend
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:
  


Current Time: Wed Jul 17 11:47:17 GMT 2024

Powered by FUDForum. Page generated in 0.04334 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top