| Overview page [message #164819] |
Thu, 20 January 2005 18:57  |
Eclipse User |
|
|
|
Originally posted by: james.willans.xactium.com
We have implemented an overview page which is returned from
GraphicalEditor.getOverviewOutlinePage. Since the update of this overview
is computationally expensive, we would like to have more control over when
this happens. Which events trigger the update of this, and where can these
be filtered?
James
|
|
|
| Re: Overview page [message #164835 is a reply to message #164819] |
Thu, 20 January 2005 19:08  |
 Brian Fernandes
Messages: 68
Registered: July 2009 |
Member |
|
|
I would like to add a problem I experience with the Overview page.
I often have huge diagrams with a large number of editParts, If the
overview view is active, most functionality in the editor works as
expected (scrolling, selection, moving), BUT menus seem to be adversely
affected.
For instance, the context menu will show up-but you won't be able to
select an Item for an extended period of time, depending on the number of
parts in your diagram. The same happens for the View and other menu's on
the Toolbar.
I tried replicating this in Logic, I created Logic diagram with 5000 LED's
over an area of about 20Kx20K pixels. The problem manifested itself here
too.
There are no issues with the menus and the same large diagram if the
overview view was not enabled.
Brian.
James Willans wrote:
> We have implemented an overview page which is returned from
> GraphicalEditor.getOverviewOutlinePage. Since the update of this overview
> is computationally expensive, we would like to have more control over when
> this happens. Which events trigger the update of this, and where can these
> be filtered?
> James
|
|
|
| Re: Overview page [message #165076 is a reply to message #164835] |
Fri, 21 January 2005 19:49 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
I think this is related to draw2d trying to find a focusable figure on
Canvas' focusGained. This will be faster in 3.1. There are simple
workaround if you find that this is your problem.
I don't see how the above problem would be sensitive to the overview's
presence. It could be something else.
"Brian Fernandes" <brian.fernandes@genuitec.com> wrote in message
news:csovk9$6hp$1@www.eclipse.org...
>I would like to add a problem I experience with the Overview page.
>
> I often have huge diagrams with a large number of editParts, If the
> overview view is active, most functionality in the editor works as
> expected (scrolling, selection, moving), BUT menus seem to be adversely
> affected.
>
> For instance, the context menu will show up-but you won't be able to
> select an Item for an extended period of time, depending on the number of
> parts in your diagram. The same happens for the View and other menu's on
> the Toolbar.
>
> I tried replicating this in Logic, I created Logic diagram with 5000 LED's
> over an area of about 20Kx20K pixels. The problem manifested itself here
> too.
>
> There are no issues with the menus and the same large diagram if the
> overview view was not enabled.
>
> Brian.
>
> James Willans wrote:
>
>> We have implemented an overview page which is returned from
>> GraphicalEditor.getOverviewOutlinePage. Since the update of this
>> overview is computationally expensive, we would like to have more control
>> over when this happens. Which events trigger the update of this, and
>> where can these be filtered?
>
>> James
>
>
|
|
|
| Re: Overview page [message #165083 is a reply to message #164819] |
Fri, 21 January 2005 19:51 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The overview figure updates itself in small tiles which paint quickly.
After each tile gets updated, the UI thread gets an opportunity to run the
event queue before the next tile is refreshed. Do you have any specific
steps or daya that show a performance problem?
"James Willans" <james.willans@xactium.com> wrote in message
news:csouul$2j6$1@www.eclipse.org...
> We have implemented an overview page which is returned from
> GraphicalEditor.getOverviewOutlinePage. Since the update of this overview
> is computationally expensive, we would like to have more control over when
> this happens. Which events trigger the update of this, and where can these
> be filtered?
>
> James
>
|
|
|
| Re: Overview page [message #165201 is a reply to message #165076] |
Sat, 22 January 2005 02:18 |
Brian Fernandes
Messages: 68
Registered: July 2009 |
Member |
|
|
Randy Hudson wrote:
> I think this is related to draw2d trying to find a focusable figure on
> Canvas' focusGained. This will be faster in 3.1. There are simple
> workaround if you find that this is your problem.
I had faced the focus issue some time ago in another plugin, and I solved
that by making one of the toplevel figures focus traversable
(IFigure#setFocusTraversable(true))
The symptoms are quite different though. With the focus issue, I couldn't
do *anything* in the workbench until Draw2d traversed through all the edit
parts, looking for something to focus on. This was when I shifted focus to
a window out of eclispe and then back in.
Here I get control of every aspect of my editor immediately, only the
menus seem messed up.
> I don't see how the above problem would be sensitive to the overview's
> presence. It could be something else.
I agree. However, the problem disappears as soon as the Overview View is
closed. I remember launching in debug mode and pausing during the time the
menu items were inaccessable, it did break into some Thumbnail code.
I will take another quick dekko at it and see if anything turns up,
Thanks,
Brian.
> "Brian Fernandes" <brian.fernandes@genuitec.com> wrote in message
> news:csovk9$6hp$1@www.eclipse.org...
>>I would like to add a problem I experience with the Overview page.
>>
>> I often have huge diagrams with a large number of editParts, If the
>> overview view is active, most functionality in the editor works as
>> expected (scrolling, selection, moving), BUT menus seem to be adversely
>> affected.
>>
>> For instance, the context menu will show up-but you won't be able to
>> select an Item for an extended period of time, depending on the number of
>> parts in your diagram. The same happens for the View and other menu's on
>> the Toolbar.
>>
>> I tried replicating this in Logic, I created Logic diagram with 5000 LED's
>> over an area of about 20Kx20K pixels. The problem manifested itself here
>> too.
>>
>> There are no issues with the menus and the same large diagram if the
>> overview view was not enabled.
>>
>> Brian.
|
|
|
| Re: Overview page [message #165284 is a reply to message #165083] |
Sun, 23 January 2005 19:52 |
| Eclipse User |
|
|
|
Originally posted by: james.willans.xactium.com
For example when we perform an animation a diagram such as laying out of
nodes, where the nodes move incrementally to their final position, with
the outline view shown it takes 10 times as long as when the outline view
is not shown (minimised). What we would like to do is switch outline off
when we know such an operation is going to be performed - the outline will
then show the starting and ending configuration of the nodes and not the
intermediate transitions rendered by the diagram. Can this be done? I've
tried Thumbnail.setEnabled(...) but this has no effect.
James
Randy Hudson wrote:
> The overview figure updates itself in small tiles which paint quickly.
> After each tile gets updated, the UI thread gets an opportunity to run the
> event queue before the next tile is refreshed. Do you have any specific
> steps or daya that show a performance problem?
> "James Willans" <james.willans@xactium.com> wrote in message
> news:csouul$2j6$1@www.eclipse.org...
>> We have implemented an overview page which is returned from
>> GraphicalEditor.getOverviewOutlinePage. Since the update of this overview
>> is computationally expensive, we would like to have more control over when
>> this happens. Which events trigger the update of this, and where can these
>> be filtered?
>>
>> James
>>
|
|
|
| Re: Overview page [message #165553 is a reply to message #165284] |
Tue, 25 January 2005 20:11 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The overview only runs when deferred events are dispatched. Your animation
should be "synchronous" and block the UI thread (for a short period of time
like 200ms), during which time deferred events won't affect anything. This
is what we do in the flow example and the palette when animating.
"James Willans" <james.willans@xactium.com> wrote in message
news:ct0v99$c28$1@www.eclipse.org...
> For example when we perform an animation a diagram such as laying out of
> nodes, where the nodes move incrementally to their final position, with
> the outline view shown it takes 10 times as long as when the outline view
> is not shown (minimised). What we would like to do is switch outline off
> when we know such an operation is going to be performed - the outline will
> then show the starting and ending configuration of the nodes and not the
> intermediate transitions rendered by the diagram. Can this be done? I've
> tried Thumbnail.setEnabled(...) but this has no effect.
>
> James
>
> Randy Hudson wrote:
>
>> The overview figure updates itself in small tiles which paint quickly.
>> After each tile gets updated, the UI thread gets an opportunity to run
>> the event queue before the next tile is refreshed. Do you have any
>> specific steps or daya that show a performance problem?
>
>> "James Willans" <james.willans@xactium.com> wrote in message
>> news:csouul$2j6$1@www.eclipse.org...
>>> We have implemented an overview page which is returned from
>>> GraphicalEditor.getOverviewOutlinePage. Since the update of this
>>> overview is computationally expensive, we would like to have more
>>> control over when this happens. Which events trigger the update of this,
>>> and where can these be filtered?
>>>
>>> James
>>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03845 seconds
] 
Search
Help
Register
Login
Home
