| Edit Part Thread [message #245905] |
Thu, 23 October 2008 22:28  |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Hi all,
This has come up a few times in the past, but I'm not sure if I've seen
a good solution. I have a quite complex edit part tree that takes a
long time to build initially, this is literally from creating the
figures (1,000s) and walking the tree and no there is no way I can
reduce that. After initial draw the part is dynamically updated but
that happens quickly enough that it isn't an issue -- I have been very
happy with GEF performance in this regard and in fact it performs
really well when compared with raw SWT drawing! A lot of this is
because I don't have to redraw every figure so I can stand the overhead
of all of those extra objects, etc..
But for building the root tree the Platform UI is locked completely ==
not good. I'm on OS X so I don't know if part of this has to do with
that.
First, I'm not sure if this is entirely a GEF issue. It seems to me
that regardless of what you are doing in a given UI thread, the
platform should be able to manage this situation, unless we are in the
middle of a global paint / refresh. OTOH if all of the figure creation
is happening synchronously during an actual paint that is going to be
an issue. Perhaps I've implemented something incorrectly such that I'm
forcing a refresh children from paint or is that how GEF is intending
to implement things?
I guess I'm wondering if this is expected behavior, i.e. whenever there
is a big refresh of all children down from root edit part the whole UI
is locked. And if that is true, what if any strategies can I use to
mitigate that.
|
|
|
| Re: Edit Part Thread [message #245913 is a reply to message #245905] |
Fri, 24 October 2008 02:40  |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
OK, on further investigation it looks like there is some kind of
thrashing that is happening here that may somehow be due to the large
number of connections I'm creating. There is an odd validation cycle
where connections revalidate which triggers a parent layour
revaildation, which triggers a connection revalidation... Somehow this
seems to be spamming the event queue or something. Anyway, wanted to
update that this does not appear to be a painting issue per se.
On 2008-10-23 15:28:36 -0700, Miles Parker <milesparker@gmail.com> said:
> Hi all,
>
> This has come up a few times in the past, but I'm not sure if I've seen
> a good solution. I have a quite complex edit part tree that takes a
> long time to build initially, this is literally from creating the
> figures (1,000s) and walking the tree and no there is no way I can
> reduce that. After initial draw the part is dynamically updated but
> that happens quickly enough that it isn't an issue -- I have been very
> happy with GEF performance in this regard and in fact it performs
> really well when compared with raw SWT drawing! A lot of this is
> because I don't have to redraw every figure so I can stand the overhead
> of all of those extra objects, etc..
>
> But for building the root tree the Platform UI is locked completely ==
> not good. I'm on OS X so I don't know if part of this has to do with
> that.
>
> First, I'm not sure if this is entirely a GEF issue. It seems to me
> that regardless of what you are doing in a given UI thread, the
> platform should be able to manage this situation, unless we are in the
> middle of a global paint / refresh. OTOH if all of the figure creation
> is happening synchronously during an actual paint that is going to be
> an issue. Perhaps I've implemented something incorrectly such that I'm
> forcing a refresh children from paint or is that how GEF is intending
> to implement things?
>
> I guess I'm wondering if this is expected behavior, i.e. whenever there
> is a big refresh of all children down from root edit part the whole UI
> is locked. And if that is true, what if any strategies can I use to
> mitigate that.
|
|
|
| Re: Edit Part Thread [message #245928 is a reply to message #245913] |
Fri, 24 October 2008 10:03 |
Eclipse User |
|
|
|
Originally posted by: shady_86.sify.com
really this is a very unexpected thing since i have tried handling large number objects together in the logic example, but it never went slow.
i will suggest you to see the shapes example and change your architecture according to it and see the results...
|
|
|
Powered by
FUDForum. Page generated in 0.02713 seconds
] 
Search
Help
Register
Login
Home
