paint optimization [message #149211] |
Tue, 31 August 2004 14:56 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
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 #149539 is a reply to message #149211] |
Wed, 01 September 2004 08:17 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
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 message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
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 message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
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 Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
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
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04630 seconds